On Tue, 21 Jan 2003, Matthew Dillon wrote:
> This might be useful follow-up work. i.e. the idea of getting rid of
> the use of the MIN and MAX macros in the kernel altogether. Though I'm
> not sure I like the fact that 'min' and 'max' in sys/libkern.h refer to
> unsigned ints (it really should be
On Tue, Jan 21, 2003 at 08:02:59PM -0800, Matthew Dillon wrote:
> :You shouldn't modify vendor code for minor purposes.
> :
> :Kris
>
> The vendor code in question has been modified *extensively* since
> it was imported, (and of course I would give Darren a head's up in
> regards to i
:I'd like to see all of these changed to the inlines in sys/libkern.h since
:the compiler will do type checking for us.
:
:This is a little more work which is why I didn't do it myself when I dealt
:with the abs() stuff.
:
:Consider this my objection.
:
:I don't think that it really stands in the
On Tue, 21 Jan 2003, Matthew Dillon wrote:
> This patch is going to go in on the weekend unless someone has any
> worthwhile nits about it. It was submitted by Hiten Pandya.
>
> The patch basically removes random MIN/MAX implementations from
> 22 files in the kernel and modifies th
Narvi wrote:
> > Priority means "how much does the group value having this
> > fixed".
> >
> > If the problem is that the wi driver panics the kernel when
> > Joe-Bob inserts a prototype card that noly he has, the severity
> > is 5 (on a scale of 0-5), but the priority on fixing it for the
> > proj
:Didn't we explicitly make it like this? ie: you'd be backing out a
:previous set of intentional commits by doing this...
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
I'm not aware of anything like that. The MIN code appears to be
in rev 1.
Matthew Dillon wrote:
>
> :On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote:
> :> This patch is going to go in on the weekend unless someone has any
> :> worthwhile nits about it. It was submitted by Hiten Pandya.
> :
> :> Index: contrib/dev/oltr/if_oltr.c
> :
> :> Index: co
:On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote:
:> This patch is going to go in on the weekend unless someone has any
:> worthwhile nits about it. It was submitted by Hiten Pandya.
:
:> Index: contrib/dev/oltr/if_oltr.c
:
:> Index: contrib/ipfilter/netinet/ip_proxy.c
:
:>
On Tue, Jan 21, 2003 at 07:25:44PM -0800, Matthew Dillon wrote:
> This patch is going to go in on the weekend unless someone has any
> worthwhile nits about it. It was submitted by Hiten Pandya.
> Index: contrib/dev/oltr/if_oltr.c
> Index: contrib/ipfilter/netinet/ip_proxy.c
> Index: ne
This patch is going to go in on the weekend unless someone has any
worthwhile nits about it. It was submitted by Hiten Pandya.
The patch basically removes random MIN/MAX implementations from
22 files in the kernel and modifies the one in sys/param.h (see the
last part of the
On Tue, 21 Jan 2003, Terry Lambert wrote:
> Narvi wrote:
> > On Tue, 21 Jan 2003, Terry Lambert wrote:
> > > The priority field is rather ridiculous, in a volunteer project,
> > > at least one that does not have some sort of scheduling enforcement
> > > (i.e. one could envision a system where all
Narvi wrote:
> On Tue, 21 Jan 2003, Terry Lambert wrote:
> > The priority field is rather ridiculous, in a volunteer project,
> > at least one that does not have some sort of scheduling enforcement
> > (i.e. one could envision a system where all changes must have PR's
> > associated with them, and
On Tue, 21 Jan 2003, Terry Lambert wrote:
>
> The priority field is rather ridiculous, in a volunteer project,
> at least one that does not have some sort of scheduling enforcement
> (i.e. one could envision a system where all changes must have PR's
> associated with them, and priority was assig
On Tue, 21 Jan 2003, Bruce A. Mah wrote:
> If memory serves me right, Arun Sharma wrote:
> > On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote:
> > >
> > > PS. I personally ignore the severity and priority fields of PRs. The
> > > importance of many PRs I've dealt with is very much i
"Bruce A. Mah" wrote:
> If memory serves me right, Arun Sharma wrote:
> > On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote:
> > > PS. I personally ignore the severity and priority fields of PRs. The
> > > importance of many PRs I've dealt with is very much inflated.
> > >
> >
> > Perh
On Sun, 19 Jan 2003, Darren Pilgrim wrote:
[snip-a-bit]
DP> > By the way, is (moderately complex) aggregated rule faster than mix of simple
DP> > rules? (for now, we drop accounting issues)
DP> >
DP> I'm not sure if the {a.b.c.0/24 or e.f.g.0/20} part is valid, but in theory
DP> this rule should r
On Tue, Jan 21, 2003 at 08:26:08AM -0800, Bruce A. Mah wrote:
>
> The severity and priority fields can be changed manually but that
> doesn't solve the problem that relying on the user-specified severity
> and priority fields for anything meaningful just doesn't work.
>
If you override the user-
If memory serves me right, Arun Sharma wrote:
> On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote:
> >
> > PS. I personally ignore the severity and priority fields of PRs. The
> > importance of many PRs I've dealt with is very much inflated.
> >
>
> Perhaps you should change the sev
Thus spake Mark Santcroos <[EMAIL PROTECTED]>:
> On Tue, Jan 21, 2003 at 01:33:01AM -0800, David Schultz wrote:
> > Thus spake Mark Santcroos <[EMAIL PROTECTED]>:
> > > Yes, that is also what I meant. We now have a swapoff() system call that
> > > does all the work itself.
> > >
> > > My idea was
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Tue, Jan 21, 2003 at 10:15:02AM +0100, Miguel Mendez wrote:
> > On Mon, 20 Jan 2003 17:59:47 -0800 Kris Kennaway <[EMAIL PROTECTED]> wrote:
> > >> [making libdialog safer }
> > > libdialog is rife with overflowable buffers..I'm not sure it would be
>
On Tue, Jan 21, 2003 at 10:15:02AM +0100, Miguel Mendez wrote:
> On Mon, 20 Jan 2003 17:59:47 -0800
> Kris Kennaway <[EMAIL PROTECTED]> wrote:
>
> >> [making libdialog safer }
> > libdialog is rife with overflowable buffers..I'm not sure it would be
> > safe even with this input method.
>
> Okay,
On Tue, Jan 21, 2003 at 01:33:01AM -0800, David Schultz wrote:
> Thus spake Mark Santcroos <[EMAIL PROTECTED]>:
> > Yes, that is also what I meant. We now have a swapoff() system call that
> > does all the work itself.
> >
> > My idea was to split that up:
> >
> > /* turn of swap device */
> > st
Thus spake Mark Santcroos <[EMAIL PROTECTED]>:
> Yes, that is also what I meant. We now have a swapoff() system call that
> does all the work itself.
>
> My idea was to split that up:
>
> /* turn of swap device */
> static int swapoff_one(struct swdevt *sp)
> {
> /* Do all things that we don't
On Mon, 20 Jan 2003 17:59:47 -0800
Kris Kennaway <[EMAIL PROTECTED]> wrote:
>> [making libdialog safer }
> libdialog is rife with overflowable buffers..I'm not sure it would be
> safe even with this input method.
Okay, I have another idea that might be a bit more productive, since the
code in lib
On Mon, Jan 20, 2003 at 11:09:36AM -0800, David Schultz wrote:
> What exactly do you need to change about the swapoff interface?
> Unless you're trying to write a module, anything that's going to
> be invasive into the swap subsystem's data structures probably
> belongs in vm_swap.c.
Yes, that is
Greetings,
Running 5.0-RELEASE,
# kldload random
induces a panic, presumably unless it is not compiled into the kernel.
sh
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
26 matches
Mail list logo
