Date: Sun, 15 Aug 2004 18:51:08 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_target.c src/sys/dev/mii mii.c src/sys/fs/fifofs fifo_vnops.c src/sys/gnu/ext2fs ext2_vnops.c src/sys/kern init_main.c kern_conf.c kern_descrip.c kern_event.c kern_exec.c kern_exit.c kern_fork.c kern_sig.c sys_pipe.c tty.c ... Message-ID: <20040816015108.GQ991@funkthat.com> In-Reply-To: <20040816014244.GB3026@green.homeunix.org> References: <200408150624.i7F6OhhR074096@repoman.freebsd.org> <20040816014244.GB3026@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Fundakowski Feldman wrote this message on Sun, Aug 15, 2004 at 21:42 -0400:
> On Sun, Aug 15, 2004 at 06:24:43AM +0000, John-Mark Gurney wrote:
> > Log:
> > Add locking to the kqueue subsystem. This also makes the kqueue subsystem
> > a more complete subsystem, and removes the knowlege of how things are
> > implemented from the drivers. Include locking around filter ops, so a
> > module like aio will know when not to be unloaded if there are outstanding
> > knotes using it's filter ops.
> >
> > Currently, it uses the MTX_DUPOK even though it is not always safe to
> > aquire duplicate locks. Witness currently doesn't support the ability
> > to discover if a dup lock is ok (in some cases).
>
> Yay, kqueues for 5.3-RELEASE that won't panic/lock up my system!! Do you
> think we should make this change now?
Yep, looks like we should...
> Also, would you mind if I gave it a quick once-over for the bigger style(9)
> concerns? No functional changes/code moving, just parentheses and such.
sure, I'd like a quick peak at the patch though (if it takes me more than
a day, go ahead and commit).
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040816015108.GQ991>