On Fri, 7 Aug 1998, Pal-Kristian Engstad wrote:
> 1.) devfs is conceptually cleaner, in that the kernel devices
> control such things as major and minor device numbers.
Put simply. the drivers know more about the system that some scripts
do.
> 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.
automagic creation of devnames is certainly a good thing. I don't want to
run MAKEDEV..whetever in 10 years time. Bear in mind that without
persistence you only get the current system configuration, ie builtin
drivers and loaded modules. You don't get devnames of modules that
haven't been loaded yet. Using tar/C is a hack for persistence.
> 3.) devfs optionally introduces a new naming scheme, preferred by
> some linux administrators.
This is a /dev not a devfs issue. The key to this is that the drivers
dictate a default naming scheme and the devfs system allows for additional
devnames defined by the sysadmin just like the existing disk-based /dev.
> 4.) devfs also makes it possible to mount your root on other
> filesystems, like e.g. a CD-ROM or a non-unix filesystem.
You sort of touched on something not really mentioned before here. If the
root partition is read only then /dev has to be separate, you cannot
populate it without going out of your way to do so. In those instances
/dev has to be on separate media.
> 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.
>
This is very minor in real world terms, especially with the dentries.
> Con devfs:
>
> 1.) It introduces new code into the kernel, some of which is
> considered bad.
As Richard said it was a learning experience. I'm sure that making it
good would be just a matter of time. If it goes into 2.2 then it will be
experimental/optional, so no problem there.
> 2.) It introduces a new optional naming scheme, and we need
> standards.
Hell someone mentioned standards. If you do that people will know what to
expect :) seriously some of the devnames have been found wanting, the scsi
devnames for instance.
How does POSIX relate to major/minor numbers. mknod isn't POSIX according
to my man page and I believe NTFS is a POSIX fs (whatever!!) but doesn't
support major/minor numbers. so what gives anybody.
> 3.) The devfs is not persistent, and can not save it's owner
> group and permission bits over reboot automatically.
devfs isn't no, but the information it gets is from the drivers. The
spanner in the works is loadable modules, but thats post-boot so would
probably be best under /var. Most types of devnames don't change
owner/mode etc. exception is terminals however these should not be
maintained over reboots. Other changes can be done post boot.
> 4.) Some people argue that all of the items pro devfs can be
> made using light-weight code, without using devfs.
read only root hasn't been mentioned. You would require something like a
ramdisk for populating it. but you have the issues of unswapable memory
again.
You probably can have various deamons running all the time just for
updating devnames but it seems a waste of resources.
>
> 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.
>
My personal conclusion
(my 0.02 worth with email duplicates that makes 1.42)
devfs threads always come up, at least richard has implemented something
like. I notice linus is staying away, probably wise.
The core problem has been people not separting the issues, what's a /dev
issue and what a devfs issue. /dev is UNIX and will stay, however the
tree below it needs sorting out, making use of directories and sensible
names. this however isn't a devfs issue.
The devfs concept is just to provide the translation between user process
to kernel drivers. People get confused by this, partly because of
richard's implementation, thinking that this is an all kernel service.
devfs deals with building up and maintaining device nodes from the
running kernel, that's all. A disk based /dev is static and is
conceptually separated from the kernel. so sync'ing the two things is
necessary (ie MAKEDEVs job).
The problem with richards devfs is the potential storage for the devnames
and there associated dentry data, the bigger the configuration the more
kernel/cache memory. If this data could be moved into a mmap and shm
segment then it becomes swappable and using a combination of
__initdata/func and modinfo sections for modules/kernel should allow for
trimming the code and data size down.
If a user space program which is invoked like kmod/modprobe is, hands
off the memory map manipulation to userspace, while a simple driver for
devfs can attach, traverse, detach and finish. Of course this is not
complete but I'm sure you get the idea.
As for the volume naming (UUID), what a excellent idea, however this isn't
/dev, devfs related. Volume names address already configured devices.
So this point is out of place like the daft raw partitions idea was.
As for a mainly userspace solution then no. Replacing MAKEDEV with other
scripts is not what is called a solution. And I don't expect a hardware
manufacturer to come up with scripts for me to use. They have touble
getting their hardware right, so lets not burden them with extra software
they have to right for installation.
Someone also mentioned adding stuff under /proc, urg!!. lets see if we
can keep /proc for hrrrrrmmmm..... processes. Other stuff like cpuinfo can
go under /config or something. simplfy procfs a bit.
If you haven't guessed I'm for the devfs idea, I believe prevention is
better than cure, and MAKEDEV is certainly after the fact solution.
karl.
(I should try smaller emails)
-
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