......
> > On Mon, 17 Feb 1997, James W. Laferriere wrote:
>
> > It's interesting to see something like this appear again. I certainly
> > agree (along with most people) that a standard should be defined.
> >
> > I've also looked at this from originally the devfs angle. Maybe I should
> > pick it up again??.
>
> -> Yes please do, I am also very interested in getting this
> done 'The Right Way' (tm;-), as Alan & Ted have said this is a
> do once and we had better be right the first time, kind of
> project.
>
very true.
> -> Alan has decree'd that he would allow these changes IF they
> did not effect the present /proc heirarchy. Being that as a
> given, then we will continue.
> Are you suggesting something like ? :
>
> /proc/proc/..
> /proc/dev/..
> /proc/system/..
>
The idea is to hang it off the / directory instead of /proc. Doing this
allow programs like ps to still look at /proc in the same way and accesses
to /dev files to be similar. This leaves a place to put information
(meminfo) and config alteration files (ip_forwarding...) - /system.
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.
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.
> > /dev/hda1
> > /dev/scsi0/disk0
>
> > /proc/1/...
> -> ^ What is this pertaining to ?, Process #1 I'll bet. OK.
>
This will just be as it currently is, however this structure is not cast
in stone. But just to re-iterate, the idea is for this directory to contain
information relating to processes only. I'll assume the self link would be
in there as well.
> > /system/modules/ide/.... <module specific stuff>
> > /system/modules/sound/...
>
> ->/system/devices/sound/... < non-modules ????????
> ^^^^^^^ <----------< Is being used as our descriptor .
> I do still beleive that the Modules & Devices systems can be
> combined into one directory, as Both are 'Drivers' just of
> differant methodologies. One is hard coded into the running
> kernel the other may or may not be loaded at any one time.
>
I agree, I used the term 'modules' purely meaning a piece of code. I didn't
intend there to be a distinction between KLM's and built-in drivers, not
in this directory anyway.
personally the name 'devices' implies a hardware thing, whereas 'modules'
encompass hardware, as well as things like filesystems. whatever suffices!
> > /system/kernel/...
> > /system/meminfo
> > /system/cpuinfo
> >
> > This is of course only a small bit. There's a alot of other things to
> > account for, like a name cache for perm's and onership of non-loaded
> > modules under the control of kerneld. However, it should give you an
> > idea of what it should look like.
>
> -> Yup, And thank you for the input... ;-)
>
Using the kerneld mechanism, we could off load symlinks into user land.
> > If you are interested, I'll get back to it, and back to looking at
> > kernel code.
>
> -> Thank You karl, And please do get involved
> the more the merry'r. ;-)
>
> JimL
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.
cya
karl.