Date: Fri, 25 Feb 2000 01:33:55 +0000 (GMT)
From: Riley Williams <rhw@MemAlpha.CX>
>> The way I envisioned it, a disc-based /dev would have (for
>> example) /dev/cpu being a symlink to $devfsroot/cpu Having
>> two hierarchies encoded isn't good.
> I'd much prefer the "/devfs" solution. That means one symlink
> for folks who want to use devfs, and one mountpoint for folks
> who don't.
> Compare this to how many symlinks we would need to put into /dev
> in the non-devfs case, assuming that people start moving into
> kitchen sink into devfs, and it's just not pretty.
Maybe I'm missing something obvious, but if the two heirarchies are
close enough together for a /dev/fs -> /dev symlink to work, they're
presumably also close enough for a /dev -> /devfs symlink to work?
If so, what's the point of this argument?
OK, suppose there are a large number of pseudo devices in /devfs:
/devfs/cpu
/devfs/microcode
/devfs/kitchensink1
/devfs/kitchensink2
/devfs/garbagedisposala
/devfs/garbagedisposalb
/devfs/....
Now let us assume that someone doesn't want to use /devfs as /dev.
There are a number of reasons why this might be the case, but let's not
rehash them now.
If programs simply access these files as /devfs/foo, then someone who
doesn't want to use devfs as their /dev directory can simply mount devfs
in /devfs, and be done with it. Folks who believe in the /devfs
relgiion can mount /devfs over /dev, and then put a symlink in so that
/devfs points /dev.
However, if programs access these files as /dev/cpu, /dev/kitchensink1,
etc., then someone who doesn't want to use devfs will have to mount /devfs
in /devfs, and then put in potentially hundreds of symlinks pointing out
of /dev to to /devfs to find all of these files.
Ergo, it's less painful *if* we decide to move thigns to devfs and start
requiring people who want certain functionality unrelated to the
original purpose of devfs to be forced to compile and load devfs anyway,
to establish a standard where programs that are expecting to look for
these magic files look for them in /devfs, much like these program
expect to look for these magic files in /proc instead.
Quite frankly, I don't see the point of moving virtual files like
/proc/cpuinfo from /proc to /dev. Programs are already written that
expects to find a large number of virtual files in /proc. Changing them
will be a massive headache, and it's not so clear that /devfs is a more
natural home for these sorts of virtual files than /procfs. Arguably
/proc/uptime has as little to do with devices as it does with processes.
I've never understood the vehemence of the folks who hate non-process
related files in /proc --- but presumably, if they were consistent, they
also wouldn't be happy putting them in devfs.
- Ted
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:14 EST