Re: tty and more

>>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 ?
>
> 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 use maybe 'sh' most of all, and it is not running in raw mode.

I am playing with VSTa remotely from my home through a modem to a PC at my
job, using a COM port. This works quite good, except I can't reboot VSTa
if needed.

>>I like the SYSV model, using STREAMS.
> ...
> I also hate code in the kernel--I'm assuming that you
> didn't mean you wanted VSTa to emulate that part of streams!

Oh no, I really agree that all code should be pushed as far out as possible.
I didn't mean I liked the STREAMS implementation, but rather the idea of
layering.

> ...
> There sort of needs to be
> such a [tty] 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.

But a server is needed for some stuff, isn't it ? If that is the case, it
might as well handle all signals generated by the keyboard. Then we have the
question of where to put other input and output processing.

The benefit of putting it in libc is that it is pushed out as far as possible,
and servers are kept as small as possible.

The benefit of having input and output processing in this extra server would
be that it is much easier for a user to create and replace it with his
favorite processing. The processing would also be asynchronous, enabling you
to use typeahead.

There is a standard list of signals possible to generate by the keyboard. It
is probably possible to change this list ! It seems VSTa has defined signals
as strings, making it possible to add and define your own types ?

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

I don't claim the readline interface is the one and true thing, but it is
interesting as a reference for how to solve similar problems. If you put
the readline functionality in libc, then all programs as well as all users
get it, either they want it or not. Someone wanting something similar
but not exactly the same would have to change the libc and recompile a lot.

This also implies that a user wanting to add a different kind of
readline interface would have to have access to the libc source code, as well
as be able to recompile all programs using the tty interface in cooked mode.

Best regards,
    Lars Pensj|
Received on Sat May 7 15:12:19 1994