On ðÎÄ, 2002-01-14 at 18:34, guran wrote: > On Mondayen den 14 January 2002 15.32, Borsenkow Andrej wrote: > > > > The main reason for devfsd is to autoload modules and manage device > > permissions not to provide legacy links. On legacy system without devfs > > modules are autoloaded basing on device numbers and you do not notice > > it. On system with devfs you not only do not have device nodes to > > trigger autoloading but you (theoretically) do not even have fixed > > device numbers because they are managed by devfs itself. > > > > Permissions management is not as critical it just comes as extra goody. > > Still it is something legacy system cannot do. > > > > If you preload all your drivers (either compiling them all into kernel > > or preloading all modules) you can omit devfsd. Permissions management > > issue still remains but it the same as on system without devfs. > >
Correction 1: it works only if all your hardware is ready when you boot. If you have any hotplug device (USB, SCSI, FireWire, Serial ATA, parallel port - whatever) _and_ it is not supported by hotplug - you need devfsd to load modules. Because most modules unload themselves when no hardware found. Correction 2: permissions management *is* critical. On legacy system permissions are persistent or *all* possible device nodes get correct permissions (e.g. via pam_console). On devfs system any node created after you have logged on needs devfsd to apply correct permissions. > > If we ever have hotplug for PCI ready ... then we return to this :-) > > The task of loading correct drivers will hopefully be done by hotplug sometime (devfsd is no more than poor man's workaround). Permissions management remains as main task always. And even then you need devfsd for legacy hardwire. I use SCSI Jaz connected to parallel port and there is *no* way for system to detect that it has been plugged in or switched on. So the only possible thing is to probe for it. -andrej
