Re: /proc file system, seems to -not- have standardisation ?

Karl R. Heyes (karl@ronin.u-net.com)
Mon, 24 Feb 1997 22:31:39 +0000 (GMT)


Well my ISP went dead on me sunday night, so my last reply didn't get on
the list, but did get to Jim.

On Sun, 23 Feb 1997, James W. Laferriere wrote:

> On Sun, 23 Feb 1997, Karl R. Heyes wrote:
> snip...
> >
> > The idea is to hang it off the / directory instead of /proc. Doing this
>
> Karl,
>
> Ouch, This does effect /dev directly, Not really what I had in
> mind. I'll also bet we get our P'p's slapped if we suggest it. ;-}

yep!. but it is sort of related. Most people tend to be open minded though.

> > allow programs like ps to still look at /proc in the same way and accesses
> > to /dev files to be similar.
>
> From what I can gather here, the Idea is to not try to alter
> both /proc & /dev as they appear today, But to Add further
> functonality to both ?
>

more or less true. /dev and /proc shouldn't be moved, however the structure
of the directories and format of the files is really the question.

> Do you have a long description of what you'd like to do ?
>

It's a pretty big change in itself, but essentially this. To have a
filesystem that allows drivers to be allocated space within it to
present there /dev/... names (with possible subdirs). This filesystem
doesn't neccessarily mean all kernel space. The use of kerneld could
be really important here. Instead of messages like 'block-major-2' being
sent, something like 'loadmod fd0' could be used.

It should be a big step closer to having read only root fs, and probably
help lookups of /dev when the rootfs is over NFS.

> >This leaves a place to put information
> > (meminfo) and config alteration files (ip_forwarding...) - /system.
>
> This starts getting into the one thing I really -didn't- want to
> do and that is scatter things outside of /proc . /proc/system
> could still be viable for your plan ?
>

think of it as purely a name change. The name proc referring to processes,
so the directory should contain process information. Information like
overall memory usage, uptime and driver configuration don't sit in the same
place as processes. So you still can group files together.

arguable you could have a tree like this

/system/proc
/system/net
/system/scsi
.
.

and not have a /proc at all.

> > Without knowing all the neccessary details (yet!) of making the / handle two
> > filesystems, one way to possibly handle it is to configure it into the VFS
> > layer. But of course the first method would be preferred.
>
> Ok, but we had better run this under the nose of the maintainers
> first and see just how they would like to see it done.
>

I see it at the moment having the the ability to mount two filesystems on /
such that a call to readdir/lookup would do a search of both filesystems.
needless to say, it's only a rough idea. Even if it uses th VFS method then
replacing it with a more generalised 'union' mount (amd term) later would
not affect user programs.

any comments!!

> > Two config files could be added to enable/disable the "/dev, /proc". This
> > means that if some admins want kmem ps or traditional devname-major/minor
> > schemes then fine.
>
> We already can dis/enable /proc at Kernel config time.
> All that you'd need, would be to dis/enable the /dev extensions
> you'd like to see in use.
>

The /system tree would contain the information files that have mentioned
before on this thread. The /proc could be configured out for kmem-ps people
but still allow them to read the driver configuration file for instance.

snip...

> > Using the kerneld mechanism, we could off load symlinks into user land.
>
> Ok, Would you please give me a reasonably easy to follow
> example of doing the above. I find myself very curious
> on this method of propigating info. to the user.
>

It's really something I thought of when addressing the issue of /dev/mouse
/dev/modem etc. They are user defined (well.. admin defined anyway) and
seeing that kerneld would be asked 'what is /dev/mouse' (as a possible
KLM) then return a symlink definition to the real /dev/.... entry. I think
that the only exception that I can think of is the /proc/self link which
would be in kernel space.

I did have a nasty thought of sticky it under the control of a kernel thread
and also giving the ability for user loadable modules. I snaped out it and
got some sleep.

> > what are people's views on defining permissions on /proc/<pid> directory's
> > so that ps can't give process information to any user. This has been
> > suggested before, but seems appropriate for this thread.
>
> To be honest I haven't heard anyones view on this subject.
> But, In the Multi-User realm It sure should be looked into.
>
> I find myself leaning toward the, If I'm the owner of the
> process I should be able to get -any- info about it I want.
> If I'm -not- the owner, then I -may- be able to get some, too
> all of the info, depending on the -real- owners wishs.
>
> IE: The Owners set permissions for the owned processes.
>
> One cavaet, root/su is -owner- of -all- processes. In that
> no-one can hide info about a process from root/su, And root/su
> can -always- change anything about a process. I Know it's
> already this way. ;-)
>

root wouldn't have to be the owner, as the permissions shouldn't affect
the root user accessing that directory or any file within it.

cya

karl.