Re: Thoughts about proc permission handling

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

>I've just been having some thoughts about permission handling within the
>proc server. What's just occurred to me is that my idea of simply having
>proc change its own IDs to match those of its current client won't work -
>the client can have as many IDs as the server.

Nah, that's an edge case. Just skip the last one if necessary--this fails
in a conservative fashion. Far better to reuse the actual kernel mechanism
than to try and duplicate it.

>BTW Andy, I'm thinking of reverting back to my original rework of the proc
>fs where we can just get a process list back rather than having to step
>through the linked list.

I'm rethinking the pstat() system call itself. It's starting to feel like
too much code, too intrusive. Perhaps it should just mmap() physical pages
and try to snapshot system state on the fly. This would make the /proc
server much more important, and much more intimate with the kernel innards.
That should probably be OK, so long as it's all in one place.

It leaves the /proc server exposed to race conditions. I used to think this
was a big enough issue that a kernel mechanism was needed. Now that we've
written it and played with it some, I'm not convinced. There are some
things (like networking) which, once you let them into the kernel, become a
serious case of the tail wagging the dog. Statistical/status inquiries
might actually fall into this category.

>... This isn't insignificant as at the moment the proc ps code
>can yield over 300 pstat() calls when we have 20ish processes (as measured
>with the code I wrote yesterday).

But it's not a part of the system where performance is important. I'd run
it in Smalltalk on a virtual machine if it would leave kernel messaging and
scheduling cleaner and more efficient.

If /proc is real-time and we leave the nrun calculation in the kernel code,
/proc could even do the load average calculations, couldn't he? He'd just
have to be sure to subtract out his own nrun-ness (or factor in a fraction
of it to reflect his run state outside of the load average calculation).

This would also allow him to inhibit (or reduce the granularity of) the
calculation when there are no clients--a nice side effect of being a server.

                                                        Andy
Received on Sun Dec 4 09:39:54 1994