devfs vs. tagged /dev [was Re: cowloop technology]

Csaba Henk csaba.henk at
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 mailing list