Subject: Re: sysctl(2) and/or /kern for system variable manipulation
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 03/26/2000 22:40:18
> As for "breaking many ordinary filesystem operations", well that's I
> think a matter of opinion and will depend strongly on your point of
> view. Certainly you don't want to have mkdir(), or link(), or maybe
> even unlink(), do anything useful in /procfs, for example.
Processes do not support filesystem operations, so any attempt to use a
filesystem interface to processes (or a process interface to a
filesystem, though nobody ever seems to consider that) will necessarily
be a poor fit. This is more or less what I meant when I wrote
>> The filesystem simply is not a good fit to many abstractions. Look
>> at all the things you can't do with procfs, for example: both things
>> you can do with processes but not procfs "files", and things you can
>> do with normal files that you can't do with procfs "files".
> You should forget about treating virtual filesystem interfaces
> exactly as files from the point of view of using all the command-line
> file manipulation tools on them and expecting something logical to
Exactly. They aren't files; why try to make them look like something
> The point of using the filesystem paradigm is to provide a simple and
> common system-call interface through open(), close(), read(), and
Why is this good?
Why should that interface be preferred over any other? For example,
why not instead make everything a socket? An AF_FILE socket would give
you access to filesystem files, an AF_PROC socket would give you access
to processes, etc.... Or make everything a sysctl MIB.
>> It's an interesting paradigm, but as I indicated above, is has the
>> problem that it ends up twisting everything into the filesystem
> That's not a problem -- it's an opportunity!
That's a matter of opinion. :-) (Actually, I think it's both.)
> The only scary thing about the "files are everything and everything's
> a file" paradigm is that naive people are prone to adding
> non-sensical features to such interfaces
Not nonsensical at all - from a filesystem point of view. This is
touching on what I meant when I wrote of twisting things into the
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B