Pro devfs:
1.) devfs is conceptually cleaner, in that the kernel devices
control such things as major and minor device numbers.
2.) devfs reduces the number of devices in /dev to a minimum, thus
reducing a number of inodes and some hard-disk and RAM. This
has also the advantage that it is easy to determine which
devices are in the system.
3.) devfs optionally introduces a new naming scheme, preferred by
some linux administrators.
4.) devfs also makes it possible to mount your root on other
filesystems, like e.g. a CD-ROM or a non-unix filesystem.
5.) devfs is also claimed to be faster, in that you do not have to
go to an external device to get major and minor device numbers.
Con devfs:
1.) It introduces new code into the kernel, some of which is
considered bad.
2.) It introduces a new optional naming scheme, and we need
standards.
3.) The devfs is not persistent, and can not save it's owner
group and permission bits over reboot automatically.
4.) Some people argue that all of the items pro devfs can be
made using light-weight code, without using devfs.
My personal conclusion:
Except from the non-persistant nature of the current devfs, I
believe the design is fruitful, new and refreshing. It has a
couple of ideas which makes sense, and it makes the whole
/dev issue easier, especially among new users of Linux.
I think we should endorse devfs. All of the con devfs arguments
are solvable. Devfs could be cleaned up, making less impact on
the source. The naming scheme, although not liked by some people,
are after all optional. Devfs *needs* to be able to save its
state on a hard medium if possible. A mount option, specifying
where to place it? And finally; the argument that you can
solve each of the problems devfs solves by coding additional
"light-weight" code doesn't hold water. Why re-invent the wheel?
PKE.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html