I'll leave the tty bit for now - I've taken a quick look at the top level
libc code, but after some recent discussions with Andy I think that there
needs to be some more work to get a more complete implementation. I
submitted a small patch to get non-blocking I/O to run OK to the rs232
server (which is what I was really working on), but other than that I guess
there's still some code to be written.
Lars Pensjo wrote:
>
> Now to another thing: The kernel is small and nice, as it only has a limited
> number of responsibilities. Among these are process management and memory
> management. It seems there are no general ways to access these
> informations. Implementing a 'ps' program would need some kind of access.
> Of course, implementing 'ps' using a /proc filesystem is even better, but that
> driver will need the kernel information access instead.
>
> It seems the kerner doesn't accept any messages by itself. I don't very much
> like the old unix idea of a /dev/kmem. It is flexible, not a pretty
> solution.
>
> Is there maybe a more general solution ?
I believe Robert Mayer is looking at adding the necessary system call to get
these sort of details back into user space. This would then allow a proc fs
to be written. One advantage with VSTa's structure is that any other
process stats (above and beyond kernel data) can be provided by the servers
themselves.
> Yet another discussion: some people wants automatic backups of files, with
> maybe a whole series with version number like VMS. Could this be implemented
> through a server that is pushed onto another file system ?
I don't see why this should be a problem. Plan 9 has a mechanism to do
exactly this. I think that the pathnames provided by the Plan 9 server are
based on the date (I don't have the docs handy) - I believe the idea's
something like:
/arc/09JAN94/fred/abcd.c
/arc/10APR94/fred/abcd.c
The first path would give "abcd.c" as it was on the 9th January and the
second would give "abcd.c" as it was on the 10th April. Perhaps in a VSTa
implementation there could be a "stat" field that could record exactly which
version of a file we have once we open it.
Certainly layering fs's shouldn't be problem - I do exactly this when I'm
working of bfs.
Regards,
Dave
Received on Sat May 7 03:27:34 1994
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:04:28 PDT