Re: DevFS vs. udev

[Mark Mielke]

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@xxxxxxxxx/markm@xxxxxx/markm@xxxxxxxxxxxxxxxxxx __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | 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...

                           http://mark.mielke.cc/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/