From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 11 Feb 2005 21:21:16 +0000 Subject: Re: [ANNOUNCE] hotplug-ng 001 release Message-Id: <20050211212116.GB13940@vrfy.org> List-Id: References: <20050211004033.GA26624@suse.de> In-Reply-To: <20050211004033.GA26624@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, Feb 11, 2005 at 01:10:28PM -0800, Greg KH wrote: > On Fri, Feb 11, 2005 at 11:46:27PM +0300, Roman Kagan wrote: > > On Fri, Feb 11, 2005 at 11:36:27AM -0800, Greg KH wrote: > > > Do one thing, and do it well. > > > > > > udev is for naming devices, not loading modules. > > > > Well currently udev is doing a lot more: serializing, waiting for sysfs > > dir to appear, etc. Not that I disagree with your first statement, > > though. > > > > > Why, each type of autoload program needs to know how to handle the > > > different bus types. So again, a single program doing a single thing > > > well. > > > > udev already pokes enough in sysfs and has quite a lot of > > subsystem-specific knowledge, so adding module name generation is not > > too much of extra functionality. > > If you look at the hotplug scripts, they really don't need to touch > sysfs at all. (Note that the scsi one does, but I think we can fix the > scsi hotplug event to solve this issue...) > > So module autoload has really nothing to do with sysfs. > > Also, udev happens for the device _class_, not the device itself. > Modules bind to devices, device classes generate /dev nodes. These > happen at two very different points in time (notibly the module events > need to happen before the device class ones are even able to be > generated.) So udev has nothing to do with loading modules. > > Also, for serialization, that's not needed for module loading as we > never unload modules automatically (that's impossible to do properly.) > > > OTOH I'm fine with them being separate programs, provided they get the > > necessary info from sysfs so that they can be used for coldplugging too. > > This will require adding wait_for_sysfs logic to them, though. > > coldplug can be a simple shell script, or eventually, something like > what udevstart is. wait_for_sysfs stuff is not needed for that at all. > > > [ BTW could you please remind the motivation for doing wait_for_sysfs > > instead of fixing the kernel to call out the hotplug usermode helper > > only after the correspoding sysfs directory has completed initializing? ] > > How does the kernel know that the sysfs directory has completed > initializing? :) > > Note that Kay has proposed making the kobject registration a two step > process, generating the hotplug event later after the kobject has set up > sysfs "enough". I'm reluctant to add that functionality as it make the > kernel more complex, and we've already solved the issue in userspace. Yeah, but the spinning costs a lot of CPU and should be avoided if it that's so easy as the proposed change. The point is that for the drivers nothing needs to change, but the class/block core can use it and it will make the timing significant better and it safes us a lot of useless stat() cycles. Kay ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel