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
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
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
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 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
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,
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
>
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
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
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-
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
"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 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
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
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:
> 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
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, 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
: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
:
:>
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
: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.
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
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
: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, 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
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
26 matches
Mail list logo
