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, 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
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 want to
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 */
static int
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, I have
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
safe even
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 to split that up:
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 severity
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
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 require
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.
Perhaps you should
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 inflated.
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 assigned
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 priority
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:
: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:
: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
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
project is probably
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 the
: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
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
24 matches
Mail list logo
