new vsta user (windbag)

Well, I'm just getting started with vsta. I have had it for a year or so, but
only recently got an extra hard drive for it (my vsta boot process currently
involves unplugging one hard drive and plugging another in since my machine
only supports 2 ide drives). So: nice system! I'd like to help out with it,
but unfortunately I'm not a very knowlegable programmer. I have never written
anything like a device driver, but I'll learn someday! Perhaps vsta would be a
good place to start. I've been reading source and skimming the list archive
(number 11 seems not to be in the vsta directory, what's up?).

So anyway, I went and upgraded to 1.6 and set up grub on my vsta hd. After
changing cons2/isr.c to be dvorak and changing caps lock to control, the system
was reasonably usable. I do have a few questions which may be silly, but I
haven't seen them on the list, so I'll ask anyway. Linux, by default, has a
high keyboard repeat rate which I rather like. Not that I know anything about
assembly, but I found the following lines in src/linux/arch/i386/boot/setup.S:

! Set the keyboard repeat rate to the max

        mov ax,#0x0305
        xor bx,bx ! clear bx
        int 0x16

so it seems to be a rather simple operation. Also, how easy would it be to
switch console video modes? I'm used to a 80x50 console, would the cons server
be the best place for something like this? Maybe have -80x50 and -80x25
command line switches or something? Unfortunately I know nothing of the inner
workings of video cards, or I'd do it myself, but perhaps it would be a mere
moment's hack for someone in the know. I'm sure relevant details can be
borrowed from linux source, or the settextmode program.

When under load, vsta seems a tad unresponsive. What I mean is, alt-f# vc
switches give a noticable pause before switching, and character input is like
typing over a 9600 baud modem line. Sometimes it seems as if characters are
being dropped. Is this normal? Maybe since the console server is just another
user-mode process, it is having to fight over the cpu? Also, vls -F takes
quite a long time to display a directory. Is this normal overhead in
interaction with the fs server? Is stat() much slower than on unix? Do
processes have nice values and priority? My machine is a 486/66, btw.

I was wondering how vsta did job control and ttys, etc. As much as I can tell,
the answer is "it doesn't", but thought I heard a mention of setsid() somewhere
back there on the mailing list. I mention this because a while back, Dan
Bernstein wrote a suite of programs called `pty' that use pty sessions. He had
a lot of interesting things to say on about how unix and posix really screws up
with ttys and job control, and how such things could be improved greatly with a
few simple changes. I wonder if anyone has thought of job control + vsta?
Things like this were mentioned in the "Ideas Summary (2/3)" message of a while
back. Perhaps the tty server is intended to do this, but I had a thought that
it would be cool to have a "job control server". What would happen is that the
stdio library (or whatever) would connect to this server, and processes would
be connected to the other end. When you suspend a process, the server moves
your shell's connection around, and maybe merges the stdout of the backgrounded
process into your shell's. Say you start a long find or something, then get
sick of waiting, so you suspend and bg. Then you don't want the garbage on
your screen, so you tell the server to connect its stdout to a file. Or say
you start up a bunch of processes, then log out. Later you can log back in and
reconnect, or give them away to someone else ("here, finish up my game of
nethack"). So the server acts like a sort of patchbay, allowing you to connect
and disconnect processes at will. Sorry if this is exactly what the tty server
you were talking about is supposed to do, it wasn't to clear to me. Anyway,
then things like ^Z and ^C can be interpreted in the console driver, to switch
tty connections around, and maybe freeze/melt processes. Then we can just tell
everyone (like shells) that we don't have job control, and they'll never worry
about it (or know).

Here's another random little idea: how about a "config server"? The unix
method is to have a million little text files spewed all over /etc, ~,
/usr/lib, ..., which all have their own syntax and quirks. Under vsta, someone
could write a "libconf" which provides a common interface for program config.
It then registers with namer conf/progname, and makes files in there. So at
any time, you can change the configuration of a daemon while it is running by
doing, say, "echo 240 >/conf/ppp/mru", or view it with cat. Then the libconf
has routines to save the config to a binary file in /etc/conf or something.
Then programs don't have to worry about all this file parsing nonsense, they
all have a consistent interface, etc. The only thing I would worry about is
whether libconf could be made flexible enough to handle all purposes.
Obviously, the simple case of config variables, like mtu in a net driver, can
be easily represented. But what about conditionals, loops, etc.? rc files
wouldn't change, of course, but maybe there could be a clear seperation between
rcs and conf files So a shell, say, would have it's .shellrc which does the
usual thing, and then a /conf/shell entry which replaces setopt (zsh), or set
-o (bash) builtins.

An even more random idea: I'm not sure what to call this, since I've never
heard of it before, but one could have "standalone threads". What I mean is,
executables which, instead of doing a fork()/exec(), do a tfork(). This would
allow you to make commands like "cd", and more importantly, "mount" external
rather than shell builtins. They might not actually be very useful, though,
since they'd have to know all about the program they were running under.
Standalone threads which had to do with common libraries (a mount command would
just have to talk to stdio libc structures, right?) could actually be useful,
though. What do people think?

Well, as I said, I'm not a great programmer. I can write documentation, though
(provided I understand what I'm documenting :) ). I figure I will first port
"sps", my /proc-using linux ps replacement, and have a look at the proc server.
Then maybe I'll write my "ls" replacement, "s", for vsta (it's one letter
shorter, there's an improvement right there!). Along the way, I would be
happy to write readmes and man pages about things I learn along the way. A
"porting" document, which includes common things involved in porting posix
programs to vsta, would be very useful and informative, not only to porters,
but to users who want to know in what ways vsta differs from unix.

Speaking of documentation, I've been having a little trouble with man. I
figured out about adding things into the map file, but roff seems to be having
trouble parsing non-vsta man pages. If I do "roff rc.1" I get pages and pages
and pages of "unknown roff macro", or something similar. I think having a
bare-bones nroff is a good idea, but it would be nice to be able to read or
convert not-so-simple man pages. Speaking of mans, has anyone given any
thought to the structure of documentation under vsta? As long as we're
breaking from tradition, why not give some thought to the online documentation
situation? I'm not a big fan of nroff (it's hard to read plaintext, it has
developed lots of hackery over the years, etc.) myself. I'm not sure what
could be used as a replacement, but my only requirement would be that it
produces good console output (so tex + tty2dvi is out), and is easily
greppable. I don't like having docs where the whole thing is organized around
hypertext, so you have to _find_ all the documentation, but I think hyperlinks
within a page could be very handy. I guess another possibility is TeXinfo,
which presumably produces nice dvis as well as info files. I disagree with the
gnu info reader, but given a decent reader and a linear document format, info
might not be too bad. Of course, a solution that lets one use plain text
pagers like less and more would be the best. So maybe nroff is doing pretty
well after all. Plain text with no markup is fine, too. I have always thought
that man should be more general: it should be able to look up arbitrary pages,
and execute arbitrary commands on them. So for traditional man pages, it would
run roff. For text files (and stray cats), it would run the pager with no
preprocessing. For .tex it would run tex or latex and, err... madodvi the
output. Ok, so I'm getting a bit ahead of things here :) I just think it
would be nice to have a unified, well defined thing to do with documentation,
that can be easily indexed and read by a user. The zsh people are using
something called yodl which can compile to nroff, TeX, info, html, and maybe
some more. Then of course there's sgml, but I haven't seen any console
viewers for that. And then html, which I haven't seen any good console
viewers for either (don't like lynx).

Also, while watching all those roff errors go by, I found out about ctrl-C, or
rather, that it seems to be lacking. I gathered that the only signal (event?)
which can't be caught is "kill". Is there an equivalent of SIGINT? All
I could find was some fakery in <signal.h>, and notify(2). Could cons2/isr.c
be modified in the same place as the #define KDB to do a
notify(0, 0, "interrupt");, or is it not so simple? How can I install an
eventaction() sort of thing? Where can I find out more info about them?

Has there been any sort of attempt at a filesystem structure standard? Since
vsta's fs structure is all fakery anyway, it seems like agreeing on standard
places for things would be pretty important. For example, all the makefiles in
the src/ dirs want to link with libs in ../../lib. Unfortunately, given
/vsta/src/bin/whatever, that doesn't work to well. I thought "oh, I'm supposed
to put srcs in the root", but then makefiles in srv/ were tacking on too many
..s. I like the plan9 style /bin union dir, with sub dirs, so you could type
disk/fsck_vfs or something. BTW again, why do all these programs have to
manually link with crt0.o and -I/vsta/include? Couldn't gcc's specs file
(which is undocumented as far as I can tell, I can't figure it out) do this
automatically? From what I can tell, vstafs is nothing to rely on right now.
There's also this bfs thing (boot file system?). It looks like it's not really
intended for use on the root partition. So is everyone just using old 8.3, no
owner/permissions FAT? Everyone seemed to agree that ext2 would be easy to
port, but it seems that the only port is currently alpha
dont-use-this-if-you-value-your-data. It would be nice to have a well tested,
high performance filesystem for vsta. I'd imagine extensions to support vsta
style file permissions wouldn't be hard, I think the hurd adds some extensions
of it's own as well. Perhaps people would be interested in (if they don't
already know of) the reiserfs, a high performance file-system being developed.
There is info at http://www.idiom.com/~beverly/reiserfs.html. I'm not sure
how well it would work with Andy's "reset at any time" policy, though.

I've had some crashes when attempting to move directories. I'll do
something like "mv src .." and that vc will freeze. All the other vcs are
fine, until I type something and press enter, at which point they freeze too.
Speaking of freezing vcs, does vsta (cons?) have type-ahead? Looking at a
struct screen s.s_buf[], it apppears it does, but you can't see it. I'm used
to typing one command while the first is completing, and I find it
disconcerting if the characters don't immediately appear. Would it be a
simple modification to have the cons server put all keystrokes on the screen
immediately, or is there no way to do it unless the app at the other end
does a read?

Thank you (Andy?) very much for the vim port, I'm glad to see my favorite
editor in vsta. Too bad it's an ancient version. Maybe the person who ported
it could tell me what exactly was involved in doing it, so I could maybe try
and port a new version (5.0something as of now, but I'm ignoring 5.0 in favor
of 4.x)? Also, someone mentioned dynamic loading under vsta. Am I safe
assuming no one has written dlopen()? The new version of zsh uses dynamically
loaded modules, this would be a good way to encapsulate vsta-specifics (mount
builtin, spiffy protections, etc.) into the mainstream distribution. I would
like zsh mostly for the command-line editing, programmable completion, and
decent globbing. How difficult is a shell to port? Something as complex as
zsh might be very difficult. As a system shell, I think es would be very cool.
It's small, reasonably fast, and very extensible and powerful. Maybe I'll try
to port that, as rc has already been done it may not be too hard.

It appears getline's idea of configuration is "modify the libc source".
Unfortunately my libc won't compile (details later). Maybe I'll get the
getline source to see if there's an easy way to add vi-style command line
editing. I'm perfectly happy with rc, I just want my customizable command line
editing and completion! Speaking of getline, I think it's mucking some things
up: if I do "cat >foo" in the interests of making a file, I get "getline(): not
interactive" or something and my prompt back.

Speaking of porting, it would be nice if porters made a little document that
describes changes they had to make to the program source. That way, when
someone wants to port a new version, or a similar command, all that work isn't
duplicated. Maybe it could even be sent to the program mainainer to put
in the official release.

I wonder if anyone is interested in a tar filesystem. I'm not sure exactly how
it would work... you'd need some sort of auto-mounting. Maybe you could modify
your 'cd' to say "if it's magic number indicates a tar or gz file, then mount
it with the fs/tgz server, and cd to it". Also, how about an ftp filesystem,
ala plan9? It seems it wouldn't be too difficult to write, in the same manner
as a fs/tgz server: if you cd to, say, /n/ftp/ftp.zendo.com, it would try to
connect to zendo. Like the tgz fs, it should do heavy caching to keep things
nice. After no access for a while, it disconnects, and removes the
/n/ftp/directory. Another advantage of this is if one user has been recently
using /n/ftp.zendo.com, another one can use it too, without reconnecting or
losing the cache. I don't think ftp allows multiple files to be transmitted at
the same time, though, so the server may have to open another connection.

Speaking of magic numbers, I've never really been very happy with them. Now
that vsta is getting its own filesystem, perhaps that hack could be eliminated?
I'm not exactly sure how to do it. Apple's type/creator fields seemed to work
pretty well, although I have heard complaints about them being prone to trouble
somehow (besides the trouble of having to register them with a central
authority). But magic numbers rely totally on convention, too. I envision a
filesystem with a type attribute, so all your gzs and gifs can lose their
DOS-like filename extensions. It would still be easy to see what they are,
since ls would of course display the file type if you wanted, and later on,
what icon they get (hopefully we'll get that far :) ). But you could also not
display them if you wanted (and maybe have ls color-code them or something),
and save directory clutter. It might be hard to get away from those silly
three letter extenions, since they are already dug in so firmly. A simple 32
bit field (or maybe 8 printable chars) would actually be pretty similar to
.blah extensions, but more well-defined (all text files would have 'nl-ascii'
or something, and .conf files would still end in .conf), more powerful (file
type globbing, etc.), and more unobtrusive (what if you get sick of seeing and
typing that extension, and you already know what file type it is, or don't
care?). I've always thought programs that rely completely on three letter
extensions were silly (DOS crashes if you rename a text file with .exe and try
to run it). Of course, a type field is the same sort of thing, but much harder
to mess up. And I'm sure something better than a plain type field could be
imagined. Dare I mention mime?

I remember a debate a while back among the plan9ers about whether arrow keys
and like should be escape sequences or unicode 'chars' (runes?). cons2 seems
to do ^[O{A,B,C,D}, which is vt100 standard, I guess. I've never really liked
the concept of escape sequences, but single characters isn't actually that
different. Some sort of seperate data path? Perhaps there could be a a vt100
cons server that supports all the old unix cruftiness, and then a special vsta
cons that's all cool and spiffy and experimental? A problem I can think of is
how would one be using the vsta shell under the vsta cons server, and then
immediately switch around as soon as one runs a unix port? Now that we no
longer have gazillions of different terminals, we could avoid the unix
term{cap,info} and have a few seperate cons servers: vt100 for compatibility,
telnet to non-vsta, etc., since it seems all the world's a vt100 nowadays, and
vstacons, which has neat vsta-specific features.

Another idea I had for a project I could possibly handle would be a syslog
server. I've always thought the traditional syslog style was rather ad hoc,
especially the facility part. A more general, flexible syslog would be a good
thing, and maybe even a secure one (so if a message says it comes from a
certain place, you know it did). I thought that facilities could somehow
register themselves so the syslog knew about them, but then we already have the
namer, which does something like that. My ideas are not clear at this point.
Perhaps the syslog() call could create a /namer/thisserver/syslog file which is
written to, and then read from by the syslogd? Or maybe the syslog server
could create its own filesystem or something. Would it be beneficial to have
permissions for a file specific to the process that created it? For example,
so a process can store info that is readable, but not writable by even the user
who started the process. This would suggest a "fake filesystem", since then
those files would disappear when the process died, and not litter undeletable
files around.

Who handles #! in vsta? When using rc, I get an exec format error, whereas
sh handles it ok. There is no mention of #! anywhere in sh.c, nor could
I find anything in kern/exec.c (or anywhere else).

I wonder what's happening with MADO? Is it still happening, slowly? Last I
heard it sounded like significant work was done, but proceding at a leisurely
pace. I have some ideas about UI sorts of things, but the mado person (Gavin?)
would probably not be interested if he was not at the point to be implementing
that sort of thing. Should I post them to vsta-win, just to see what people
think?

Oh, one more thing. What I am ultimately interested is a midi sequencer. I
have had plans to write one of my own, but unfortunately the existing midi
drivers under linux are limited in accuracy to 1/100 sec. I was wondering
what kind of accuracy could be implemented in vsta. I know it's not a real
time system, but given a need to tag incoming data with timestamps, how
accurate could vsta be? Could we give the server a nice high priority so it
would have lots of interrupts to service the midi port? In the vsta readme
Andy said he wanted "enough RT support to do com port drivers", which implies
yes. BTW, how do you nice things under vsta? The docs mentioned that, given
it's leaf/node scheduling algorithm, you could gaurantee a certain process
group would never use more than, say, 50% cpu time. How would you do this?
Something I've always thought unix should have is a major page fault limit:
limit the number of pages of swap a process can pull in every second. That
would alleviate the problem of one misbehaved process thrashing the disk
and cheating everyone else, while the cpu is sitting around at 3% (I see
a lot of this, since I have 6MB RAM).

I also had a crash: I compiled the libc, and it got to the mkshlib part. It
printed two lines (Library libc.a @ 0x60001000) and froze. After a bit, I
eventually got:

Assertion Failed line 323 file ../kern/vm_page.c
set_core: bad index

and was dumped into the kernel debugger. I don't know many commands in
the kdb (quit and proc :) ), so I reset eventually. Every time I try to
compile the libc, it crashes at that same line, although in different ways
(sometimes it goes into ignore-the-user mode).

I've got vim 4.2 working except one thing: vsta doesn't seem to have select()
(or poll(), I guess that's a systemV thing), and vim wants to use that for,
well, waiting on fds. I looked at the vim 1.24 port, and was more confused
than enlightened (in the routine supposed to wait for fd input, uses select
in 4.2):

RealWaitForChar(int ticks)
{
    if (ticks != -1)
        return 0;
    return 1;
}

Notice it doesn't actually do any waiting? Anyway, the only non working thing
about my vim is multi character bindings, which I figure is since it isn't
waiting properly... but they work on vim 1.24!! How are you supposed to
wait on multiple fds in vsta?

Seems rename() hasn't made it into the headers yet. No big deal, just a
reminder.

So, anyway, if anyone has a simple project for me to do, I would be interested
in helping out. I could write documentation: as you can see, I am capable of
being very verbose :)

Oh, btw: in case anyone is interested, there is a libgc with a drop-in
garbage-collecting replacement for malloc() freely available, developed by the
Xerox PARC people. It shouldn't be too hard to port to vsta, since it also
compiles on the mac, os/2, amiga, and windows (as well as unix, of course). I
don't know how it stacks up in efficiency, strength, etc. with other gcs, but
it's there and it's free and portable. It's designed to be thread-safe. If
people are interested, I could try to port that too.

btw again, vsta's cpp doesn't seem to be the same as the gnu one. It chokes on
certain #if lines, which makes porting rather more difficult.

btw again again, "root" is a more appropriate name than ever in vsta, since
it is the root of the permissions tree. Does anyone know where that name
on unix came from?
Received on Tue Nov 4 22:03:06 1997