Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Dec 2011 22:41:58 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r228209 - head/sys/kern
Message-ID:  <20111202214158.GE60194@alchemy.franken.de>
In-Reply-To: <4ED94215.7030109@FreeBSD.org>
References:  <201112022119.pB2LJEqJ009294@svn.freebsd.org> <4ED94215.7030109@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 02, 2011 at 04:24:37PM -0500, John Baldwin wrote:
> On 12/2/11 4:19 PM, Marius Strobl wrote:
> >Author: marius
> >Date: Fri Dec  2 21:19:14 2011
> >New Revision: 228209
> >URL: http://svn.freebsd.org/changeset/base/228209
> >
> >Log:
> >   - In device_probe_child(9) check the return value of 
> >   device_set_driver(9)
> >     when actually setting a driver as especially ENOMEM is fatal in these
> >     cases.
> >   - Annotate other calls to device_set_devclass(9) and 
> >   device_set_driver(9)
> >     without the return value being checked and that are okay to fail.
> >
> >   Reviewed by:	yongari (slightly earlier version)
> 
> Hmm, I've always thought that new-bus overused M_NOWAIT.  There are a 
> few places where M_NOWAIT might be appropriate (e.g. from pccbb's 
> interrupt routine when a cardbus card is inserted), but the boot time 
> probe can certainly use M_WAITOK instead.  Even the pccbb case could use 
> M_WAITOK if it were simply deferred to a taskqueue (which it probably 
> should be anyway, probing and attaching a driver to a new card is far 
> too expensive to do directly from an interrupt handler).
> 

In general the use of M_NOWAIT vs. M_WAITOK in bus methods is also very
inconsistent across device drivers. We should decide how to handle the
standard case, document it and fix things up accordingly ...
I agree that M_WAITOK should be used in most of these cases.

Marius




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