Re: Reflection and /proc

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Dominik Kubla writes:
> On Mon, Mar 01, 1999 at 06:51:58PM -0800, Scott Lurndal wrote:

> Did you ever try  to port from/to HP-UX? Their pty  handling will drive you
> crazy...

There is a defined way to handle pty stuff. Linux just got support for it.
You will need my new "ps" program to handle it, along with other stuff.

> guess i  know your answer:  speed. But then look  at NT, they  sacrificed a
> reasonably good  architecture (WRT device drivers  and user-interface) when
> moving from 3.5 to  4.0. Result: a buggy video driver  can crash the system
> which was very hard in 3.5.

Solution: use Open Source video drivers so that you can fix the bugs.
There is nothing wrong with video drivers in the kernel.

>> /proc  is  an  overloaded,  overburdened   interface  in  linux.  It  was
>> originally  designed  as  a  replacement for  ptrace  (/proc  stands  for
>> process), and linux has extended it to  be more than it was designed for.
>> The original  /proc implementation  in SVR4  provided a  binary debugging
>> interface and there  was no text in  the kernel at all, thus  no need for
>> nationalization in the kernel. Having  the ps(1) command format and print
>> the /proc/$$/status file  from its binary contents is  much more flexible
>> from a nationalization standpoint.
>
> I stand corrected.  But that perfectly well demonstrates why i am against
> proprietary linux extensions.  A split into a SVR4-compliant procfs and
> a kernfs a la BSD would have made more sense, but...

Linux /proc was designed to be like Plan 9 /proc, not SysV /proc.
I believe SysV /proc is a less accurate ripoff of the same thing.

There isn't any reason why we can't support everything.

Add "kernfs" as an alternate name for the proc filesystem.
They should contain the same files, but some files may be invisible.
(You can access /proc/stat but you can't see it with "ls /proc".
You can access /kern/12345 but you can't see it with "ls /kern".)
This gives you clean-looking directories with nearly perfect compatibility.
Make the /proc directories respond to read() and other SysV needs.
The file type can be normal or directory as desired - they both work.
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html