So, in essence you had something implemented in userspace but you put
kernel support in to:
- improve performance
- provide a conceptually cleaner system.
So you provide a basic interface in the kernel to support something in
userspace, where you design an interface specific to the userspace
component.
> This is, in fact, analogous to saying that device nodes are kernel
> concepts (which they are), but the management of them (which doesn't
> need to be fast) belongs in userspace.
I agree. I see devfs as providing a basic interface (which improves
performance and provides a conceptually cleaner system) for
userspace. Something like devfsd can provide the policy. Devfs itself
(well, actually the individual drivers) provide a basic default policy
(a minimal policy) and userspace can do the rest. However the
interface has been designed specifically for the userspace component
(devfsd) that provides the policy. I see the existing rc.devfs script
that can tar/untar permissions as a more primitive userspace policy
component.
However, I don't expect you to see it this way ;-)
BTW: one way I can see devfsd being used is that devfs is mounted onto
/devfs or some such, and devfsd fills a disc-based /dev with symlinks
to /devfs, or creates real device nodes. This would satisfy people who
don't like the default policy of devfs (permissions and naming
scheme). In this way devfs becomes an information provider, one that
is unified for all devices.
Not that I expect to use it this way myself, but the possibility is
open.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html