Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!mmdf
From: archer%segin4.segin.fr@relay.prime.com (Vincent Archer)
Newsgroups: comp.os.minix
Subject: Re: Revision of PC 1.5.10 ps.c
Message-ID: <30221@nigel.ee.udel.edu>
Date: 12 Sep 90 15:43:46 GMT
Sender: mmdf@ee.udel.edu
Lines: 61

Sean Goggin <sean@watcsc.waterloo.edu> writes:
>Better I think is /dev/usermemory
>that you can mount on /proc
>and use ls to see processes or ps
>shared text could be shown as a hard links
>
>total 654
>-rw-r--r--   1 sean     minix      55800 Sep  5 16:11 D#PID1
>-rw-r--r--   2 sean     minix      29089 Sep  5 16:11 T#PID1
>-rw-r--r--   1 sean     minix      15901 Aug 25 00:03 S#PID1
>-rw-r--r--   2 sean     minix      55800 Sep  5 16:11 D#PID2
>-rw-r--r--   1 sean     minix      29089 Sep  5 16:11 T#PID2
>-rw-r--r--   1 sean     minix      15901 Aug 25 00:03 S#PID2

Another plan9/Killian's process file system addict?

This looks great. But did you think about the actual implementation under
Minix? Let's take the problems in sequence:

* FS caches the blocks it reads. So, when you do the ls twice on /proc, you
  would cache the situation on the first call, then (if cache is bigger) gets
  the cache information on the second call (and not see the new ls at all).
  This leads to the implementation of "non-cacheable" or "volatile" (in
  reference to the ansi-C notion of "volatile" variables) devices; i.e. block
  devices you cannot cache at all: any read option leads to a new read of
  the block you reference.
* You wouldn't manipulate the /proc directory. Do not forget to mount it as
  a read-only device. Then you fix FS so that it takes in account the read-only
  attribute in all functions (try cmd1|cmd2 while in a directory on a ro fs!)
* Then you need a task to give you such infos. The obvious task is MM: it's the
  one who knows best how to manipulate processes memory. One problem remains:
  If you use MM for such a task, then MM can send messages to FS (when it loads
  file images, forks, or things like that), and FS can send messages to MM
  (when it needs an inode descriptor, or the directory contents). Guess what
  will happen soon? Yes, you're right: a deadlock looms ahead...
* The FS does not gets inodes & things like that from devices. It gets blocks
  which contains inodes and decode them. So your device driver need to encode
  (in FS way, so it depends from FS; no more FS-independency anymore) the
  info and guess from FS block numbers which info it should send. Verrryyy
  simple... :-)
* What would happen if the user decide to open some file (for example S#00015
  to get the argument list from the process space), and then the process dies
  and gets waited for. The process should be purged, but then the "file" is
  open, so it shouldn't until close time. And the driver is never notified
  that file are opened. Only FS know about this.
* Last (but not least): how about 68000 users. There's no separate I, D & S
  spaces on 68000s. And the address space does not start to 0, it starts at
  some specific address. So ps() would not be portable anymore (whereas it is
  now).

That's all for today :-)

Feel the complexity (and feasability) of your suggestion. For Minix 6.9, I
can't say :-), but not with the current Minix architecture.


    Vincent


Vincent Archer             | Email:archer%segin4.segin.fr@relay.prime.com
"Wrong thing to say, right thing to do; do as I say, not as I do..."