> 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.
I tend to disagree, with two points. 1. Well yes, module autoloading may be done without sysfs just fine (but see below). Yet, module autoloading isn't the only "usage" of hotplug subsystem, right? Ie, in 99.9% of times when a hotplug event is emitted, there will be other scripts executed to handle the event, and that scripts will depend on sysfs information. 2. And even for module autoloading, $DEVPATH/driver symlink is very-very handy, as it's the only (and good) way to check whenever we really want to mess with all the module stuff for this device at all: if the symlink is present, just do nothing. Modprobe - if we're moving this functionality into modprobe which seems to be a good idea - while loading matching modules one by one, can check $DEVPATH/driver to see whenever it should stop walking the list. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
