Hi Ted.
>>>> 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?
Oooooopppsss...Slight typo there, /dev/fs should've been /devfs
>> 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
Those make sense...
> /devfs/kitchensink1
> /devfs/kitchensink2
> /devfs/garbagedisposala
> /devfs/garbagedisposalb
Those might come one day - presumably when Linux is used to
control the "Total Home Control (tm)" system...
> /devfs/....
However, I know what you mean...
> 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.
Alternatively, they can mount /devfs as /devfs and put a symlink
in with /dev -> /devfs unless I'm mistaken?
> 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.
Alternatively, they could just make /dev a symlink to /devfs if
I'm not mistaken?
> 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.
I can agree with that without problem as it's what I would choose
to do anyway.
> Quite frankly, I don't see the point of moving virtual
> files like /proc/cpuinfo from /proc to /dev.
If there's going to be any cleanup of /proc it needs to be a
sensible one, and that isn't it.
Given the ability to design from scratch without throwing the
idea of backwards compatibility out of the window, here's what
I would do:
1. Rename the current procfs as knlfs since that's what it
really is: A means to get at kernel internal data.
2. Have the knlfs root directory contain the following
entries only - the paths shown assume that knlfs has
been mounted as /knl on the system in question:
/knl/dev Directory for devfs to be mounted on.
/knl/proc Directory holding the virtual process
directories that currently clutter up
/proc and with the same internal use
as they currently have.
/knl/sys The current /proc/sys directory.
/knl/misc Directory holding the files that have
no real home at the moment, such as
/proc/cpuinfo and the like.
3. Define a new procfs filesystem that consists only of symlinks
to the equivalent location in knlfs that can be mounted on
/proc for backwards compatibility with existing entries, and
make it clear from the start that no further entries to it
will be accepted under any circumstances as it is strictly
for backwards compatibility.
4. Have procfs check whether knlfs has already been mounted when
an attempt is made to mount it, and refuse to mount if not.
The only problem I can see with this approach is that existing
Linux setups make no allowance for it, and that would need to be
dealt with as part of any implementation proposal.
> 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.
If something like the above was done, that shouldn't be a big
problem - that's what the redefined procfs is for.
> Arguably /proc/uptime has as little to do with devices as
> it does with processes.
It's not the only one - /proc/cpuinfo is in the same position.
> 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.
That's why I can see something along the lines of the above
suggestion being the only way to satisfy both schools of
thought.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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:21 EST