Re: tty and more

[lars@distinct.se (Lars Pensjo) writes:]

>It seems a lot of input and output processing is handled by libc instead of
>a driver. Is this a temporary solution, or the way it is supposed to be ?
>There will be problems, like no echo when typing characters ahead.

This is the way I intended it. Deviating from UNIX's typeahead echo
behavior is not that big a deal--for instance, you don't get typeahead
echoing in most applications these days anyway, since most applications seem
to run in raw/cbreak/noecho modes. I decided that I could live with
incompatibility in this area.

>I like the SYSV model, using STREAMS.

I hate streams. It is complex, especially in the areas of flow control and
out-of-band messages. I also hate code in the kernel--I'm assuming that you
didn't mean you wanted VSTa to emulate that part of streams! I've supported
streams stuff for a living in past lives, and--like the Plan 9 folks--don't
particularly like it.

>The idea is to have a "basic" device
>driver, which only does the hardware communication. On this driver, you
>push another protocol which implements other things. In the tty case, the
>pushed handler would take care of CR-NL mapping, echo, erasing characters etc.

Such layered functionality be easy enough to emulate in VSTa, since the TTY
processing is in a library in ring 3. Code it up and then add it as a new
file descriptor layer.

>This model seems to be close to the way VSTa is working, or could be working.
>The filesystem for example, consists of a low level hardware device driver,
>with a filesystem manager "pushed" onto it. Communication is done through
>messages.

You *could* push all of it out to another server. There sort of needs to be
such a server anyway--to map ^C and stuff to events. But VSTa's design
philosophy was to push the code as far "forward" in ring 3 as possible.
Thus, code in your address space in preference to code in your own server,
in preference to a system server, in preference to the kernel.

>Another benefit of having a special server taking care of input and output
>processing, is that it can be used elsewhere. For example, when defining
>pseudo ttys. A pseudo tty could maybe simply be created by pushing such a
>handler on a pipe ?

Since the C library takes a raw data stream (with type=c) and puts a TTY
interpretation onto it, pty's are even easier since all they have to present
is a raw data stream.

>The Gnu readline functionality could be implemented as a server to be pushed
>onto a tty, instead of building it into the shell or libc.

Why a different server? It works pretty well in a library. It isn't built
into the shell; it's in the library. The intent has always been to use
shared libraries; it's pretty much known how to do this, it's just that
nobody has gotten around to it--yet.

We might have to agree to disagree here--I put things in the library in
preference to in another server. Libraries are fast to call, easy to debug,
and easy to replace.

>The STREAMS mechanism in SYSV is very fast. Would a similar mechanism based
>on messages involve too much overhead ?

Streams is very slow and clunky. Sequent multiprocessor streams with a
couple CPUs tossed in worked pretty smoothly (would that we could all
afford such hardware!). It's also *very* easy to break, and it has tons of
painful edge conditions.

>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.

Someone is working on a pstat() system call which will use a defined
interface to extract state. He is indeed planning on doing a /proc server
to then provide this information to the rest of the system. I helped create
pstat() for HP/UX, and it worked out pretty well.

>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.

Right. Where practical, the kernel provides mechanism. The server provide
policy. Interpreting messages is policy, and pstat() should really suffice.
/dev/kmem would never fly anyway--too many race conditions in accessing
values, especially in a kernel where most data structures are allocated
dynamically. VSTa is coded for symmetric multiprocessing, which makes it
even worse.

>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 ?

Backups are a part of a number of related storage management issues. It
would easy to provide virtual disks ("volumes") with one or more storage
entities ("plexes") below them. Plexes are then made of ranges of subdisks,
which are parts of real physical disks. So if you have two plexes under a
volume, you have a mirror. If you then disassociate one, you have taken a
snapshot. You can put it under some other volume and dump it off to tape.
A cool variation is where you don't really have all that disk, but the
volume management uses copy-on-write tricks to provide the illusion of a
second plex long enough to write it to tape.

This is fun to implement until you start hitting exceptional conditions (I/O
errors and power hits) during changes in configuration. Like you add a
second plex to a volume, and it starts pulling a copy of the current data
from the first plex to get up to date, and then the power goes out. You
have to keep state so the right plex's data gets honored for the volume on
restart, and the second plex picks up (roughly) where it left off.

You might be happy with the Berkeley RAID code, at least as a starting
point. I've never worked with this code myself--most of my experience is
with Veritas. But I've read a lot about it and you may as well steal from
it if the source is unencumbered.

                                                Regards,
                                                Andy
Received on Fri May 6 20:46:01 1994