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....