Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 2009 14:30:09 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Scott Long <scottl@samsco.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, Attilio Rao <attilio@freebsd.org>, svn-src-head@freebsd.org, Kostik Belousov <kostikbel@gmail.com>, "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: svn commit: r192535 - head/sys/kern
Message-ID:  <alpine.BSF.2.00.0905221428310.17322@fledge.watson.org>
In-Reply-To: <200905220921.34785.jhb@freebsd.org>
References:  <3bbf2fe10905210629p46c7a204v6863aaba77354462@mail.gmail.com> <20090521194243.GW1927@deviant.kiev.zoral.com.ua> <3bbf2fe10905211511g53defb6cmac45fc2469cc64f@mail.gmail.com> <200905220921.34785.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 May 2009, John Baldwin wrote:

> On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
>> At this point I wonder what's the purpose of maintaining the sleeping 
>> version for such functions?
>
> Actually, I still very much do not like using M_NOWAIT needlessly.  I would 
> much rather the solution for make_dev() be that the 1 or 2 places that need 
> to do it with a mutex held instead queue a task to do the actual make_dev() 
> in a taskqueue when no locks are held.  This is basically what 
> destroy_dev_sched() is doing.  Perhaps a make_dev_sched() with a similar 
> callback to be called on completion would be better.  Having a device driver 
> do all the work to setup the hardware only to fail to create a node in /dev 
> so that userland can actually use it is pretty rediculous and useless.

It's certainly true that we don't support failing calls to if_attach(), on the 
basis that backing out partially successful interface attaches isn't pretty. 
Likewise, if_detach() will drain task queues (etc), so also may sleep.  I 
think it's not unreasonable to require a full thread context for major 
interactions with device/interface registration, etc, and I don't see that 
changing for the network stack.  We're still shaking out bugs from code that 
thinks it's OK to free inpcbs in arbitrary contexts (which it's not, because 
we have to drain timers).

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905221428310.17322>