Re: ttys

Andy Valencia From: <vandys@vsta.org> wrote:
: Let's see, that'd be cons2, MGR, rs-232, telnetd. Of these, MGR and telnetd
: would probably be happier using PTY's rather than cooking up TTY handling
: themselves. Drivers (RS-232 and cons2) clearly would benefit from some
: common code for "being" a TTY.

Ahh, I didn't notice the pty server. I'll have to look into this.

: No argument; you have to remember that what the messaging API is, and how
: it's used, were evolutionary. Some of the really odd ones are to support
: efficient scalability (such as the server interface to TCP).

I didn't much care for the server semantics of the ka9q interface,
so I deviated with lwIP (which is somewhat working now, there's
some code on my web page for the courageous). I see that the
interface provided for less round message round trips, but the
concept bothered me. I feel it loses some of the power of making
everything a file if you have odd functions (such as seeks on
a listen socket) to perform operations. As a good example, think
of how this would integrated into a shell scripting environment.
I suppose that a seeking utility could be written, but using
just rstat/wstat/read/write allows for full network access with
the existing shell environment.

This is getting somewhat off topic here, but I dislike the heavy
use of absolute port names for similar reasons. I understand
their utility in situations such as bootstrapping, but going
through the mount table provides greater flexibility. If
a utility or server opens net/inet:tcp/clone
then there is no way to override the networking stack (short
of providing a cmd line argument to override the path). If on the
other hand the path /net/tcp/clone is used, then the utility
will happily work with whatever service is mounted there, wether
it be the local networking stack, some sort of socks proxy, or
a remotely mounted networking stack. Plan9's 8.5 uses this
mechanism to great effect.

: There's
: certainly good cleanup potential in this area. However, I'm deep in a
: coding effort on a completely different front. Even the run-time system
: isn't VSTa (it's a much simpler environment), thus for now I can only
: provide moral support and technical consultation.

understood. I don't expect you to commit your life to VSTa in
perpetuity :)

: I'm aware that many potential contributors are frustrated because I neither
: actively work on VSTa, nor open it up via, say, SourceForge, to commit
: access for others. The problem is that VSTa was a very important exercise
: in "going it right" for me, and I would rather have it coast to a
: halt--aging, but still clean and consistent--than have it become yet another
: inconsistent mess of code thrown in from many directions.

I understand completely. VSTa is interesting because of some novel
design choices and elegance of design.

That said, however, there are other outlets where network development
is starting to crystalize. There is some activity around

   http://vsta.quackerhead.com:8080/vsta/FrontPage

which uses a newer source control system with public access to
a heavily modified VSTa kernel. Much of the development has
been in-kernel but maintains the same system call interface.

I've been working primarily in userland stuff myself. I would really
like to see clustering happen in VSTa. I don't think it would require
much work at this point, and am quite happy to provide my code
in patch form for now. (I would love to maintain a public VSTa
source tree, but the task would require more time than I could commit,
and there doesn't seem to be a large enough community of contributors
to warrant it at this point).

: Andy

Tim N.
Received on 29 Jul 2004 00:09:27 GMT