Re: DevFS vs. udev

Mark Mielke
2003-12-23T18:01:25Z

On Wed, Dec 24, 2003 at 12:19:00AM +0800, Ian Kent wrote:
> When this thread first started I had a look at the code and, I must admit,
> it is a little untidy (ugly actually). I think it would require a
> considerable amount of effort just to make it maintainable. Maybe then
> some of the problems (whatever they are) would present themselves.
> So it's deprecated in 2.6. Is this only because no one is willing to take
> on maintenance of it or is it to late?

In true open source style, it is never too late.

All you need to do is convince enough influential people to include *your*
fixes into the tree. At this point in time, it looks like you would need
to improve the devfs code quite a bit to change their minds. udev, once
implemented, will be elegant (interface-wise) competition.

The arguments against udev that I have seen to date are:

1) Device metadata does not belong in user space. To this, I say 'why'?
For *decades*, /dev has existed as a file system without *any* kernel
support. udev follows in these steps. devfs is the drastically
different model that has been difficult to make work right in all
circumstances. /dev has a file system only had problems of capacity.

2) udev is slow. To this, I say 'prove it'. Why should it be slow?
As a tmpfs file system, I *assume* that the vfs name lookup routines
are implemented quite efficiently. What would make udev be slow?
How often are devices added and removed from the kernel? Does anybody
have a real life scenario where a kernel model is added and removed
hundreds of times a second?

3) udev takes up more memory. Why should this be the case? It is in
user space, meaning that for a running system, it, and it's
configuration file don't even need to take up swap space. The only
space requirements are those dictated by the file system. For tmpfs
I doubt the space is that much more than devfs (both need kernel
data structures to be initialized and in existence). For a regular
file system, it isn't a fair comparison, but the cost should be
quite minimal. They're device files. They don't have data outside
their inode structure.

I blame the udev people for this thread. :-) They should have their beast
*finished* already, and their sales skills need to be improved. Volunteer
techies! Hehe...

mark

--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...