[Quinn Dunkan <quinn@envy.ugcs.caltech.edu> writes:]
> 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
I'm not sure I *like* the hyper repeat rate....
>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 serve
>r
>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.
Actually, it'd probably be better to spend that time on putting a decent
video mode into MGR. Right now it tops out at 640x480, which is getting
long in the tooth with a 8 MB video card playing into a 20" monitor. Then
you could get multi-fonts into all the windows, which would be more useful
yet.
>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 anothe
>r
>user-mode process, it is having to fight over the cpu? Also, vls -F takes
>quite a long time to display a directory.
Yes, the scheduler treatment of cons2 is unkind. The problem is that the
process looks like a CPU-bound one, with reasonably large sleeps in between.
This would *really* be solved by some sort of inheritance, but that's
something which loads a system with more overhead. A simple fix would be to
give cons2 a real-time priority.
>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've noticed this, too, but [gv]ls are new additions, ported years ago by
Dave Hudson, and I didn't spend any time analyzing where they spend their
time.
>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() somewher
>e
>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 ha
>d
>a lot of interesting things to say on about how unix and posix really screws u
>p
>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?
Yes, and we ended up decicing that the signal-based job control model
actually is better than you'd think up front. But first the basics of
keyboards generating interrupts. Note that MGR already does this (well, it
uses a pull-down item, but the *mechanism* is all there). And processes do
have signal groups. I actually have some code I'm cooking to keep track of
TTY mode and setting of VINTR, and generate signals to the right processes
at the right time.
>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.
Actually, it was proposed as simply a config library. I'm not sure an
additional server adds all that much over editing of config files. Of
course, if you want to hack it out and see if it's nice in reality, I can
fold it in.
>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 woul
>d
>just have to talk to stdio libc structures, right?) could actually be useful,
>though. What do people think?
Since it's going to intimately re-tread the shared data structures, right
off the bat you need to figure out how you protect critical sections.
> I figure I will first port
>"sps", my /proc-using linux ps replacement, and have a look at the proc server
>.
A nice ps(1) replacement would be fine. In fact, it would just become the
VSTa ps, I think. Did you write the original sps, from the days of V7?
>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.
That would be cool. Like most programmers, I think documentation is a fine
thing, but I always end up doing the coding part most of the time.
>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.
On a 386, it was a real feature that "roff" (which is a clone of the
original; NROFF was a spin-off of it, thus "new roff") was much, much faster
than GNU [nt]roff. With even the smallest machines sporting Pentium II's
and 16 megs of RAM, perhaps the time has come to take on some more overhead
on this front. I'm open to suggestions.
>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 th
>e
>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 though
>t
>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 woul
>d
>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).
I like lynx pretty well, but it *is* a little, um, rustic. These days I
can't imagine building a hypertext structure using anything but HTML.
Perhaps HTML generated by some other tool and source language, but HTML
nonetheless.
>... For example, all the makefiles i
>n
>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 suppose
>d
>to put srcs in the root",
Hmmm, I thought I fixed all of that. Relative paths should point at the
right thing, unless I made a mistake. Note that especially in the src/bin
area, include/ shifted "up" a level relative to them several years ago.
> 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?
Mostly, history. In the case of libraries, it's intended that you build
against the libraries freshly cooked from source. Since the advent of
shared libraries, this doesn't make all that much sense any more.
>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 reall
>y
>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.
:->. Yeah, somebody asked me if I designed my car so I crash into it every
night. No, but if I crashed my car as often as I crash my computer, I'd
have to see about it!
>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.
On CONS:0 (Alt-F1) you should see a server croaking. Probably DOS. I'm not
aware of any outstanding problems in this area, but many of these are
dependent on the geometry of your filesystem.
>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?
All cooked mode processing (including editing, echoing, and so forth) is
done by getline() within libc. The console server doesn't know about TTY
modes, editing, or anything. If you really wanted to do flashy hacks, you
could have a typeahead "popup" show up as you typed ahead.... It'd have to
be behind a command switch, since I know it would drive *me* crazy.
>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)?
You're welcome. It's my favorite editor, too. I don't recollect anything
earth-shaking, and a port should be much easier now, since a lot more of
VSTa exists than back then. The one real bug I had to hunt was a place
where vim was accessing a buffer after free()'ing it. It made regular
expressions work incorrectly, I think. I can't believe they haven't found
this problem and fixed it by now.
> 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(): no
>t
>interactive" or something and my prompt back.
I had a problem with window resizing in the same area. getline() should
probably be taught how to try stdin or stderr if stdout appears redirected.
>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.
Guilty as charged. All I can tell you is that many of those commands ported
as I wrote missing pieces of libc, found kernel bugs and/or bugs in the
parts of libc I had previously written, and tried to guess whether it would
be easier to hack the ported source, or hack the system.
>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).
It's in the shell. See the exec.c area.
>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'm afraid it's dead. I would cheerfully be proved wrong.
>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.
Probably you could. I'd guess that in addition to low latency, you need a
high resolution clock. You could build a kernel with HZ set to 1000, and
accept a little more overhead, for instance. Or on Pentium and later,
there are CPU resources which help with fine resolution timing.
>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?
Heh. Write a UI, and then exercise the kernel mechanism. During bringup I
hacked it to see if it would work (it did), but it never became pressing
enough to code up. It'd probably be by way of the scheduler control
syscall.
>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).
There was a paper which described an "inactivated" state which controlled
the damage a single thrashing process could cause. It was present in HP/UX,
for instance. It mostly helped for those then-popular test programs which
malloc()'ed a maximum size VM area, then modified it randomly.
>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).
Wow! That's a pretty serious crash, and not one I recognize. Can you get a
"bt" output, and send it to me?
>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.
Implementing select() requires an async messaging connection to the servers
of your target FD's. So until a datagram service is put in the kernel, the
best you can do is poll the target FD's yourself. Now, an immediate
question for this port is why is there a need to block on an arbitrary set
of file descriptors? In my port of MGR I converted to using threads, and
ended up with a much more efficient implementation.
>btw again, vsta's cpp doesn't seem to be the same as the gnu one. It chokes o
>n
>certain #if lines, which makes porting rather more difficult.
No, it's the standard 2.x one which matches the rest of the tools. Use -v
(or was it -V?) to see who's invoking what.
Regards,
Andy
Received on Mon Nov 17 10:10:20 1997
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:43 PDT