> By author: Nathan Hand <nathanh@chirp.com.au>
> > HPA, would you be open to the idea of /proc/devices. This won't be
> > a terrific loss of functionality from the existing devfs.
>
> I have thought a lot about this, and I have been trying to avoid
> sounding like I flame. I *do* believe that devfs is a very inelegant
> solution, but it is a solution to a real problem. It is not, in my
> opinion however, the *right* solution.
[...]
> The right solution -- which the devfs people have correctly identified
> -- is a user-space daemon. However, once you have the user-space
> daemon, "devd", I believe you neither need nor want the virtual
> filesystem, in the general case. However, I can understand that in
> some configurations (like embedded systems) it may be desirable.
>
> This is what I would like to see:
>
> * A device daemon, devd, which can add devices on demand. I was
> thinking of one which would receive data packets like the following:
>
> <stub_name, type, major, first_minor, count, naming_scheme>
>
> e.g.
>
> <"ttyS", char, 4, 64, 192, "serial">
>
> ... where "serial" would mean the daemon should find the iterator
> for this particular class in "/usr/lib/devd/serial.so".
OK, we agree that fundamentally, the kernel has to provide device
availability information in a consistent and coherent manner to
user-space. Either /proc/device_notifier or devfs can provide
this. There are two ways that /proc/device_notifier could work:
- it's a true notifier, and doesn't mantain state (i.e. a list of
what's already there). I see this as totally unworkable because devd
would then not know about devices found before it starts
- it *does* maintain state, which is then a degenerate case of devfs.
So a stateful /proc/device_notifier could work. But I think devfs is
a better approach, because:
- it does not require the daemon to parse a file to work out what
devices are present. A filesystem is a natural way to present a tree
structure; a file is not. Devfs is moving towards a structure that
also reflects the physical topology of the hardware (i.e. bus# and
slot# will appear in device paths), which will reinforce this point
- not having the virtual FS means you don't trap FS events (like inode
lookups) which means that you can't do module autoloading, nor can
you speculatively create arbitrary namespaces
- since you need to store the device tree structure in the kernel
anyway (see above), you may as well allow it to be mounted, which
gives maximum flexibility to users (and adds very little extra
code).
/proc/device_notifier is a functional subset of devfs, but prohibits
users to make the choice to have a virtual /dev. As I've said time and
again, devfs gives *choice*. People can not use it at all, or mount it
elsewhere and use devfsd to manage a disc-based /dev. Despite (often
offensive) claims to the contrary, devfs won't stop people from
maintaining their traditions.
> * devd should not *delete* devices in normal operation, unless they
> have been superceded. Deleting device nodes is generally a
> destructive operation.
Well, I don't agree, but that's a policy issue that the user can
decide.
> Notice that this interface would *also* be usable for devfs (which
> would have to include all the various iterators etc in kernel space,
> but it would have to anyway), which makes devfs an optional,
> isolated feature. This is a Good Thing: I don't have anything
> against devfs as an *isolated* feature for the people who want to
> use it (lazy/careless admins, embedded systems...) I *do* have a
> problem with it becoming ubiquitous, and I do have a problem with it
> being a requirement for each device driver. However, with this
> configuration devd would effectively be the "standard" mode of
> operation, and devfs would be an "alternate", using the same
> interfaces.
Having devfs in the kernel *absolutely does not* mean that each device
driver has to call <devfs_register>. In the early days of the patch,
not all the device drivers I use were patched. Nevertheless, my system
continued to work.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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.tux.org/lkml/