[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
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT