>>1) IT SHOULD NOT BE PRETTY. No tabs to line up columns. No "progress
>>bars." No labels except as "proc comments" (see later). No in-line
>>labelling.
>
>It should not be pretty TO HUMANS. Slight difference. It should be >pretty
>to shellscripts and other applications though.
If this is the case, why are we using ASCII for everything? If the only
interface to /proc will be applications, then we could just as well let the
application turn four bytes into an ASCII IPv4 adddress. We could easily
have it set up to parse using the format [single byte type identifier (ie 4
for string with the first byte of "data" being the string length, 1 for
unsigned int, 2 for signed int, 19 for IPv4, 116 for progress bar,
etc.)][data]. Let people standardize away. Am I missing the point?
I think every aspect of an OS should be intuitive (so long as it is
efficient), which IMO /proc isn't. If this means splitting it in two, as
some have suggested, so be it. It certainly should have a design
guideline/spec so we may at least be consistant. Just my 2 coppers.
Will Knop
[email protected]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
William Knop ([email protected]) wrote:
>>>1) IT SHOULD NOT BE PRETTY. No tabs to line up columns. No "progress
>>>bars." No labels except as "proc comments" (see later). No in-line
>>>labelling.
>>
>>It should not be pretty TO HUMANS. Slight difference. It should be >pretty
>>to shellscripts and other applications though.
>
>If this is the case, why are we using ASCII for everything? If the only
>interface to /proc will be applications, then we could just as well let the
>application turn four bytes into an ASCII IPv4 adddress. We could easily
>have it set up to parse using the format [single byte type identifier (ie 4
>for string with the first byte of "data" being the string length, 1 for
>unsigned int, 2 for signed int, 19 for IPv4, 116 for progress bar,
>etc.)][data]. Let people standardize away. Am I missing the point?
ASCII is readable by all languages with little programmer effort. In C, you
can use a simple scanf, Perl and shells like plain ascii best.
When /proc is turned into some binary interface we'd need to create little
programs which read the binary values from the files and output them on
their stdout, which is quite cumbersome, IMHO.
>I think every aspect of an OS should be intuitive (so long as it is
>efficient), which IMO /proc isn't. If this means splitting it in two, as
>some have suggested, so be it. It certainly should have a design
>guideline/spec so we may at least be consistant. Just my 2 coppers.
Yes, maintain compatibility for 2.6 and try to dump it for 2.8.
Heck, 95% compatibility could even be achieved using a 100% userspace app
which serves the data over named pipes.
--
Erik Hensema ([email protected])
I'm on the list; no need to Cc: me, though I appreciate one if your mailer
doesn't support the References header.
On 6 Nov 2001, Erik Hensema wrote:
>ASCII is readable by all languages with little programmer effort. In C, you
>can use a simple scanf, Perl and shells like plain ascii best.
Right. Use scanf and you'll be spending the rest of your life chasing
buffer overflows. Dealing with text efficiently is not "simple." If it
were, CS students wouldn't take so long to learn how to process text inputs.
And perl handles binary as well as text. It can deal with binary faster
than it can text, but most people are too lazy to use binary formats with
perl. (I've seen a few, but they were all custom web applications.)
>When /proc is turned into some binary interface we'd need to create little
>programs which read the binary values from the files and output them on
>their stdout, which is quite cumbersome, IMHO.
So, do you run 'free' or 'cat /proc/meminfo'? 'uptime' or 'cat /proc/uptime'?
'netstat', 'route', 'arp', etc. or root through /proc/net/*? I bet you use
'ps' instead of monkeying around in all the [0-9]* entries in /proc. The
fact is, we already have "little programs" converting, shuffling, reformating,
and printing out those values.
However, yes, there are useful "human" elements in /proc. And they really
are there for the sole benefit of a human (eg. /proc/scsi/scsi, /proc/modules,
/proc/slabinfo, etc.) The bigger picture is that they don't particularly
belong in "/proc" -- the thing originally created to access the process table
without rooting through /dev/kmem. (Raise your hand if you were around for
this.)
>Yes, maintain compatibility for 2.6 and try to dump it for 2.8.
Heh. It took how many years to get "2.4" stamped on a version? I'm guessing
2.5 will not exist for several months and the actual "stable" 2.6 will not
be available until 2005.
>Heck, 95% compatibility could even be achieved using a 100% userspace app
>which serves the data over named pipes.
Screw backwards compatibilty. Sometimes you have to cut your loses and
move on. We don't want to end up like Microsoft and the whole brain-fuck
that is their dll world. (Yes, they knew it was stupid. And yes, they
would love to abandon it, but it's far, far too late.) We switched to ELF,
abandoned libc4, etc. Add another to the pile.
--Ricky
On Tue, Nov 06, 2001 at 05:09:28PM -0500, Ricky Beam wrote:
> On 6 Nov 2001, Erik Hensema wrote:
> >When /proc is turned into some binary interface we'd need to create little
> >programs which read the binary values from the files and output them on
> >their stdout, which is quite cumbersome, IMHO.
>
> So, do you run 'free' or 'cat /proc/meminfo'? 'uptime' or 'cat /proc/uptime'?
> 'netstat', 'route', 'arp', etc. or root through /proc/net/*? I bet you use
> 'ps' instead of monkeying around in all the [0-9]* entries in /proc. The
> fact is, we already have "little programs" converting, shuffling, reformating,
> and printing out those values.
Yes, but I meant a program which reads a single binary value and outputs it
as ascii, as a generic layer between the binary /proc and the ascii world
of shell scripts.
I don't like a binary /proc.
> However, yes, there are useful "human" elements in /proc. And they really
> are there for the sole benefit of a human (eg. /proc/scsi/scsi, /proc/modules,
> /proc/slabinfo, etc.) The bigger picture is that they don't particularly
> belong in "/proc" -- the thing originally created to access the process table
> without rooting through /dev/kmem. (Raise your hand if you were around for
> this.)
I've been around for six years (that is, six years on Linux, not quite as
long on lkml), which isn't quite long enough, I think.
But I agree: /proc is populated with files that don't really belong there.
Maybe everything should be moved to /kernel? (except for the process info,
offcourse).
[...]
> >Heck, 95% compatibility could even be achieved using a 100% userspace app
> >which serves the data over named pipes.
>
> Screw backwards compatibilty. Sometimes you have to cut your loses and
> move on. We don't want to end up like Microsoft and the whole brain-fuck
> that is their dll world. (Yes, they knew it was stupid. And yes, they
> would love to abandon it, but it's far, far too late.) We switched to ELF,
> abandoned libc4, etc. Add another to the pile.
It will be very, very hard for distributors to create a distribution which
runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
we must assume rewriting things like procps, init scripts, etc. will only
start as soon as 2.6 comes out. We should provide some transitional period
for userspace to adapt, but make clear to everybody that compatibility
isn't going to last forever.
--
Erik Hensema ([email protected])
> > >Heck, 95% compatibility could even be achieved using a 100% userspace app
> > >which serves the data over named pipes.
> >
> > Screw backwards compatibilty. Sometimes you have to cut your loses and
> > move on. We don't want to end up like Microsoft and the whole brain-fuck
> > that is their dll world. (Yes, they knew it was stupid. And yes, they
> > would love to abandon it, but it's far, far too late.) We switched to ELF,
> > abandoned libc4, etc. Add another to the pile.
>
> It will be very, very hard for distributors to create a distribution which
> runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
> we must assume rewriting things like procps, init scripts, etc. will only
> start as soon as 2.6 comes out. We should provide some transitional period
> for userspace to adapt, but make clear to everybody that compatibility
> isn't going to last forever.
You must have forgotten about 2.5 which should serve as a transitional
period just fine. By the time 2.6.0 is about to be released I'll be damned
if init scripts and the rest proc related hadn't made their transition.
What was said there about making a transition for the better and M$ dlls
aswell as ELF binary format and libc4, I'd say ditch it even if we planned
to jump from 2.4 directly to 2.6.
Erik Hensema writes:
> On Tue, Nov 06, 2001 at 05:09:28PM -0500, Ricky Beam wrote:
>> So, do you run 'free' or 'cat /proc/meminfo'? 'uptime' or 'cat
>> /proc/uptime'? 'netstat', 'route', 'arp', etc. or root through
>> /proc/net/*? I bet you use 'ps' instead of monkeying around in all
>> the [0-9]* entries in /proc. The fact is, we already have "little
>> programs" converting, shuffling, reformating, and printing out
>> those values.
>
> Yes, but I meant a program which reads a single binary value and
> outputs it as ascii, as a generic layer between the binary /proc and
> the ascii world of shell scripts.
The following prints a single value as ASCII for Linux, Solaris,
AIX, Tru64, HP-UX, and any other POSIX system.
ps -o uid= -p 1
This is what you are supposed to do. With the above, you can write
portable shell scripts that work on any UNIX. (real UNIX + Linux)
> Maybe everything should be moved to /kernel? (except for the process info,
> offcourse).
...
> It will be very, very hard for distributors to create a distribution which
> runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
> we must assume rewriting things like procps, init scripts, etc. will only
> start as soon as 2.6 comes out. We should provide some transitional period
> for userspace to adapt, but make clear to everybody that compatibility
> isn't going to last forever.
The app fixing starts immediately for stuff in /bin. It is all
the k-apps and g-apps that will lag.
Splitting /proc can be done. Start by mounting procfs twice.
Make non-process stuff in /proc invisible, but still available.
Then in /kernel the process stuff can be disabled. The proc fs
code can even register two filesystem types, with different
default mount options. After a while, /proc/cpuinfo and such
can emit warnings. (2.5.z for z>42, and 2.y.z for y>6) Then for
the 3.1 kernel (10 years away?) the old crud gets removed.
On Wed, Nov 07, 2001 at 07:22:16PM -0500, Albert D. Cahalan wrote:
> Splitting /proc can be done. Start by mounting procfs twice.
> Make non-process stuff in /proc invisible, but still available.
> Then in /kernel the process stuff can be disabled. The proc fs
> code can even register two filesystem types, with different
^^^^^^^^^^^^^^^^^^^^
||||||||||||||||||||
this is the key part. two filesystems and union mount should satisfy
backward compatibility needs while lspci and friends are migrating to
/kern.
this makes it a distribution issue, not a kernel issue, and there is no
need for special backwards-compatibility stuff in either kernfs or
procfs.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
john slee writes:
> On Wed, Nov 07, 2001 at 07:22:16PM -0500, Albert D. Cahalan wrote:
>> Splitting /proc can be done. Start by mounting procfs twice.
>> Make non-process stuff in /proc invisible, but still available.
>> Then in /kernel the process stuff can be disabled. The proc fs
>> code can even register two filesystem types, with different
> ^^^^^^^^^^^^^^^^^^^^
> ||||||||||||||||||||
>
> this is the key part. two filesystems and union mount should
> satisfy backward compatibility needs while lspci and friends
> are migrating to /kern.
>
> this makes it a distribution issue, not a kernel issue, and
> there is no need for special backwards-compatibility stuff in
> either kernfs or procfs.
No, not a union mount. We didn't have that last time I looked,
and I have some doubts that it would work all that well. Even
if it does work, it doesn't provide drop-in kernel compatibility
and doesn't help encourage transition.
It is possible for a single filesystem driver to register more
than one name. For example, once ext3 is fully trusted it could
register an "ext2" type so that we don't need an ext2 driver or
admin headaches. The sysv filesystem driver does in fact register
itself under several different names for compatibility reasons.
So the code in fs/proc could register both "proc" and "kern".
This lets us keep the code intact while preparing for a future
split into separate drivers.
It would be reasonable to have a proc filesystem that could
hide or disable half of the content -- either process files
or the misc junk.
Let's have a filesystem mounted as type "proc" hide everything
but the process directories by default. You can still read
/proc/cpuinfo, but you can't see it when you do "ls /proc".
Let's have a filesystem mounted as type "kern" disable the
process directories by default.
During transition, you could specify options to get:
1. today's /proc, with perfect compatibility
2. the above, except "ls /proc" won't show misc junk
3. the above, plus a warning when non-process stuff is touched
4. only the process directories
5. misc junk alone, w/o the process directories
The only difference between "proc" and "kern" is the default.
These would be the same:
mount -t proc -o misc-only /mnt/foo
mount -t kern /mnt/foo
After a while the "proc" default changes to #3, then to #4.
Then a while later support for #1, #2, and #3 dies as today's
proc filesystem is finally split in half. Transition done!
On Thu, Nov 08, 2001 at 03:14:32AM -0500, Albert D. Cahalan wrote:
> No, not a union mount. We didn't have that last time I looked,
i was under the impression al viro had them planned for 2.5...
hopefully i'm right as i find them rather useful at times under other
systems (openbsd)
> and I have some doubts that it would work all that well. Even
why not? the two namespaces should not clash... and i really hope that
there aren't any tools out there referencing proc via inode num. what
problems do you see?
> if it does work, it doesn't provide drop-in kernel compatibility
> and doesn't help encourage transition.
it doesn't exactly discourage transition either, and i don't see how
changing proc to hide/not hide stuff encourages it. at some point it
has to be a distribution issue, regardless of the transitioning scheme.
if a union could be made to work (and as above i'd like to know why it
couldn't, if only for my own education :-) it means you don't have to go
removing stuff later on.
> It would be reasonable to have a proc filesystem that could
> hide or disable half of the content -- either process files
> or the misc junk.
>
> Let's have a filesystem mounted as type "proc" hide everything
> but the process directories by default. You can still read
> /proc/cpuinfo, but you can't see it when you do "ls /proc".
> Let's have a filesystem mounted as type "kern" disable the
> process directories by default.
imho this violates the principle of least-surprise, although i suppose
if you're mounting the fs you're probably expecting it so its probably
ok.
curious,
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson