Ted, I may be wrong, but as I understand it part of the issue is that
/proc does not handle permissions properly (if at all) while devfs does
(even if not everyone is thrilled by how they are handles, at least there
is some attempt to do so)
David Lang
On Fri, 25 Feb 2000, Theodore Y. Ts'o wrote:
> Date: Fri, 25 Feb 2000 18:29:34 -0500
> From: Theodore Y. Ts'o <tytso@MIT.EDU>
> To: Riley Williams <rhw@MemAlpha.CX>
> Cc: Theodore Y. Ts'o <tytso@MIT.EDU>,
> Linux Kernel <linux-kernel@vger.rutgers.edu>
> Subject: Re: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode
>
> 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/
>
-
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