Messages in this thread | | | Date | Tue, 6 Jan 1998 00:46:09 +1100 | From | Richard Gooch <> | Subject | Re: PROPOSAL: /proc/dev |
| |
Andrea Arcangeli writes: > On Sun, 4 Jan 1998, James Mastros wrote: > > >On Sun, 4 Jan 1998, Andrea Arcangeli wrote: > >> On Sat, 3 Jan 1998, Richard Gooch wrote: > >> > >> >The reason my scheme doesn't depend on kerneld is that if a driver is > >> >built-in/loaded by a boot script, the /dev entries for that driver are > >> >registered in the startup code. So, on a system like mine where all > >> >drivers are either built-in or automatically installed by a boot > >> >script, /dev would be fully populated. An attempt to open(2) an entry > >> >in /dev which did not exist would cause devfs to return -ENODEV > >> >because kerneld isn't running. > > ...and if kerneld is running kerneld will "mknod" the device in /devfs.
No, kerneld will load the module and the driver will call dev_register() which will create the entry.
> >> - You could implement that more easily without use kerneld. > >Yes, but then we don't have module autoloading. > > I am not talking about modules. The open(2) implementation that Richard > proposed in the paragraph above is whole related to static device and not > only module. > > >> - I think this is totally wrong for programs or people that check in /dev > >> for a device before try to open it, or at least is a mess. > >WHAT!!! The whole point of a virtual devfs is that you can do a "ls /dev" > >to see what devices are currently accessable. And most actions on a divice > >start with a call to open() (or mount()). > > Richard in the paragraph I quoted, proposed a devfs implementation that > don' t show what devices are currently accessible, but only the ones > opened(2).
No, *all* devices available through built-in drivers and loaded modules are shown. And devices registered through modules previously loaded but now unloaded are also shown.
> >> - If you want to make something useful, your devfs must be populated from > >> _all_ kernel devices at boot with 600 permission and it must not remove > > Obviously I want to mean _all_ and __only__ kernel devices linked or > insmodded with the kernel.
Er, yes, that's what I suggested...
> I know but I am a bit conservative when all just works perfect and > efficient...
Well, I don't agree that the existing scheme is efficient. It "works" but it's clumsy.
Regards,
Richard....
| |