devfs vs. tagged /dev [was Re: cowloop technology]
csaba.henk at creo.hu
Sun Jan 22 16:10:07 PST 2006
On 2006-01-21, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
> A devfs is not going to impact performance. That isn't the problem
> with it. There are three problems with it.
Maybe I missed something, but as I see this thread mentioned performance
only in connection with GEOM, not devfs.
> First, the dynamic nature of a devfs means that set permissions
> and ownership for devices are not 'sticky' across reboots unless you
> add hacks to adjust them on boot.
What's wrong about it? The same regards to sysctls, net device settings,
and in general, to any userspace tunable kernel parameter. In a sense,
permissions of /dev entries in static /dev are the same as lines in
> Second, devfs does not solve the basic incorrectness of relying on the
> device namespace to list all available devices (e.g. all slices, all
> partitions, all ttys, all ptys, and so forth) when what you really want
> is simply a namespace interpretation that routes a device name to the
> proper device code.
OK, after some thinking, I guess I got it. You mean that the VFS
component in resolving "ad0s1" is bloat, and the core system interface
should get rid of it.
> Third, one of the reasons a devfs is created is to get rid of the
> major/minor number paradigm. I think this is a grand idea, and FreeBSD
> has done it, but I don't think you need a devfs to accomplish this
> feat. I think all you need is to have base names in a special
> filesystem or filesystem overlay and a VFS layer which parses the name
> out and accesses the correct device with the correct parameters.
After reading this paragraph, and your other related post in this
I don't understand how your "tagged /dev overlay" idea differs from
devfs. That would be a filesystem which routes path names to device
drives... ain't that devfs? Or when you mention "devfs" you refer to the
design of FreeBSD devfs?
More information about the Kernel