DragonFly BSD
DragonFly kernel List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Csaba Henk <csaba.henk@xxxxxxx>
Date: 23 Jan 2006 00:10:07 GMT

On 2006-01-21, Matthew Dillon <dillon@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?


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]