Re: Process lists

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

>What I was thinking was to have a single directory of "process files". What
>I'm not sure about is the format these should take. Some elements, eg the
>protection IDs can just be handled through the FS_STAT mechanism. The
>problem comes with things like the count of threads, process name, elapsed
>times, etc, and how we represent them.

The format can be fiddled back and forth forever. I'm not sure it's all
that critical. The important part is that it be available from a server
for net mounting.

The other strange part is that I'm pretty sure this needs to be a pretty
fancy server. If we have him redirect signals and ptrace handling, then we
allow cluster-wide debugging and process management. So the server would
have to have a root ID, and then switch his abilities on the fly as he acts
on behalf of his various clients.

>I guess the choice is fairly simple - use libpio and pull info out in
>binary, or put the info out in text format make things human readable.

I vote for text. Makes it easier to share resources across different
processor types.

>I've looked at the the plan 9 docs and they seem to have also used a
>hierarchy of per-process files, but again they don't provide me with any
>definitive answers. The plan 9 approach does have some quite interesting
>ideas though, like being able to send events to a process via the proc fs.
>I'm not really sure if this gives us much useful, but I'd guess that this
>sort of thing might be interesting in a distributed system.

It allows you to manage a remote process as if he was local using only
remote mounting of filesystems. I imagine remote filesystem mounting to be
the "engine" of all clustering.

>I'd like to be clear on what if anything I may want to add to the pstat()
>syscall to implement the proc fs well before I submit my large kernel diff
>collection.

So long as the call lines up in a basic way, the sizeof(struct) trick allows
us to add incremental fields without too much worry.

>... the remote access is the thing I'm really
>interested in looking into next year.

Me, too. With debugging and networking (plus or minus bugs), we just need
/tcp and a little black magic to start mounting remote servers. It's
taken longer than I hoped, but that's what day jobs do to you.... :-{}

                                                Andy
Received on Tue Nov 15 08:33:35 1994