Date: Sat, 7 Apr 2012 21:15:04 -0600 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@FreeBSD.org> Cc: current@FreeBSD.org, Nathan Whitehorn <nwhitehorn@FreeBSD.org>, drivers@FreeBSD.org Subject: Re: device_attach(9) and driver initialization Message-ID: <13B344FC-AD72-4CF5-AA7A-4C1BDE9F0A7D@bsdimp.com> In-Reply-To: <4F80B2FE.1030007@freebsd.org> References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <4F80579B.4040205@freebsd.org> <20120407151514.GW2358@deviant.kiev.zoral.com.ua> <4F80B2FE.1030007@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 7, 2012, at 3:34 PM, Julian Elischer wrote: > On 4/7/12 8:15 AM, Konstantin Belousov wrote: >> On Sat, Apr 07, 2012 at 10:04:59AM -0500, Nathan Whitehorn wrote: >>> On 04/07/12 07:50, Konstantin Belousov wrote: >>>> Hello, >>>> there seems to be a problem with device attach sequence offered by = newbus. >>>> Basically, when device attach method is executing, device is not = fully >>>> initialized yet. Also the device state in the newbus part of the = world >>>> is DS_ALIVE. There is definitely no shattering news in the = statements, >>>> but drivers that e.g. create devfs node to communicate with = consumers >>>> are prone to a race. >>>>=20 >>>> If /dev node is created inside device attach method, then usermode >>>> can start calling cdevsw methods before device fully initialized = itself. >>>> Even more, if device tries to use newbus helpers in cdevsw methods, >>>> like device_busy(9), then panic occurs "called for unatteched = device". >>>> I get reports from users about this issues, to it is not something >>>> that only could happen. >>>>=20 >>>> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called >>> >from newbus right after device attach finished and newbus considers >>>> the device fully initialized. Driver then could create devfs node >>>> in the after_attach method instead of attach. Please see the patch = below. >>>>=20 >>> Something like this would also be very useful for drivers that need = to >>> interact across the device tree, if newbus called it only after all >>> drivers have been attached. Drivers that need to see other = potentially >>> attached drivers now need to do some hacks with SYSINIT. Would it be >>> possible to do this? I don't think it changes the functionality you = need. >> I am definitely fine with postponing a call further, but I am not = sure >> how to define that point and how to implement your proposal. I am = mostly >> thinking of the case of kld being loaded, since for compiled-in = drivers, >> there is simply no usermode to make the havoc during attach. >=20 > no, Geom starts tasting disk devices as as soon as you make the = device. Which is why the typical way to cope with this is to not create the = device until you are ready to service requests for it. The other method = is to have a flag that's only set after you actually are ready that the = open routine can check and keep people out of the rest of the devsw = functions by returning ENXIO or similar error. Warner >> For the boot time attachments, I am not sure when to declare the end. >> E.g. USB does asynchronous device discovery. >>=20 >> Could you prototype a change that would do what you propose ? >=20 > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to = "freebsd-drivers-unsubscribe@freebsd.org" >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13B344FC-AD72-4CF5-AA7A-4C1BDE9F0A7D>