VSTa - First Impressions

First, I have to take an initial moment to applaud for all you VSTa coders.
I could go on about all the reasons I like what I see, but you already know
them, so I'll refrain.

I retrieved "vsta.tz" and installed it on my machine. It's a 486 with a
Adaptec 1542 and I had VSTa up and running in under 10 mintes. No matter how
unpleasant running in a DOS filesystem is, it certainly makes starting up easy.

Although I do have a problem. I have not yet had time to look into why it
occurs, because I was busy elsewhere (see below). After I log in and move into
"/", an "ls" will cause a kernel trap (message similar to "boot 8 exit", but
I forget exactly) and doing "q" to return from the kernel debugger renders
everything pretty much useless. I'm not very concerned because I may be the
victem of ignorance more than a system bug. If this rings any bells though,
let me know.

After getting VSTa up and running, (ohh and doing a self-hosted compile. I
guess I just had to.. it was all too easy) I moved to the mailing list archives.
THAT was a project. I think it's fair to say that I have read nearly all the
archived mail. I may have missed one here or there, but not many. I'm left
with a few questions which either were discussed but not answered in the
archives, or were just spurred from archive discussion.

---[ Shared Libraries ]---
First, Shared Libraries. How did they end up getting implemented? Is there
an archive of the "shared lib mailing list"? I looked through the libc code
for mapping the actual library into the processes address space, however, I'm
a little foggy about what happens next and how their implemented. The archives
would be great, because if there are reasons that some methods were decided
against (shlib server, etc.) I am interested in knowing what they were.

---[ scheduler ]---
Also, what happened to the idea of "moving the scheduler out of the kernel"?
It was brought up in the mailing list sometime ago and was never noticed
by anyone. Going with the "less in the kernel is more" idea, why wasn't this
discussed? I believe QNX uses this approach and allows the scheduler to share
the address space of the kernel to help performance. While this dosn't buy
you anything in terms of protection, it does buy you something in terms of
flexibility.

I'm not really advocating one way or the other, I'm merely asking what the
opinions of others are. I think that allowing the flexibility to write your
own scheduler is on of the more interesting prospects of a microkernel,
and being able to do so while retaining compatibility (read, no source or
binary changes) with the "microkernel proper" is enticing. However, I'm
not really aware of possible performance penalties.

---[ CVS ]---
CVS. I have had some limited experience with CVS and I agree with those who
suggested it's use for the management of the project source. Andrew said he
was going to do this, did it happen? (this is more a bit of curosity than
anything I guess).

---[ Capabilites ]---
Is this an official term? I have seen Andy refer to this as "VSTa protection"
and such too. I read one of the Plan9 papers which didn't make any mention
of Capabilites (as far as I remember). Is this a Plan9 term? It seems that
especially in the VSTa white paper, "Capabilities" seems to be almost a proper
term for the VSTa system of security.

More importantly, is this term one which should be perpetuated?

[end questions]

I "took notes" so to speak when I went through the mail archives. There is
alot there to learn from, however, some will be more intersted in just learning
about what you DID do and not how you got there, and so I'm putting togeather
the information that I gleaned from the archives. I hesitate to call it a
"manual", more sort of a guide, but we'll see what comes of it.

The design of VSTa is proving itself to me as far as managability is concerned.
I find it far easier to read the code to learn what is going on than in other
kernels/systems I have looked at. Some of this may be due to the "relatively"
small size of the VSTa project as well, however, it is undoubetly laid out
in a way which was easy for me to quickly find my way around. Don't quote
me, but I almost find it pleasurable to read the code. This is possibly also
because of the pretty rigid formatting rules which have been used throughout.

--[ A bit about me and how I found VSTa ]--

If this is already getting too wordy for you, just go ahead and skip this,
it's just provided for the curosity bound. I have been a Linux user since the
early 0.95 days. I'm a student at the University of Illinois at
Champaign/Urbana. I do most of my "for money" work programming
on NEXTSTEP.

        While Linux provides a rich functional base, I have been in
dislike of it's statically defined nature and "recomple the kernel" setup.
I don't like it's lack of threads, I could go on. A year ago I began to
look for alternatives. First in the Linux[ms]s (linux on mach) project.
Then in the Hurd (again mach). After a while I stumpled upon QNX. Which,
IMHO, has an extremely elegant design. However, QNX is commercial, and no
source is available.

        Anyhow, the recent postings on c.o.l.d about interest in
making a microkernel version of Linux sparked me to start doing some research.
I'll admit, that my original goal was to go out and look and see what was out
there that could help bring a microkernel alternative to the Linux community.
I have now, however, abandoned this approach, as I think Linux is just fine
the way it is for some, and it's not going the directions I want. I think
getting a MK os built and to the place where Linux is, as a pinnacle of free
software, would be a better solution. If nothing else, it'll provide a base
of free code for people to really discuss the macro vs. micro design tradeoffs
with some more facts, instead of religion (or microkernel bashing).

VSTa seems the most "practical" of the microkernel's I found, as well as the
one most aligned with my ideals of MK design. I must admit, the idea of having
non-POSIX security initially caused some aprehension, but after reading a
description of the VSTa capabilities I found in the mail archives, I am
converted. (the description of POSIX mapping onto VSTa capabilites along with
the Capabilites example in the VSTa white paper provided a fairly clear
picture of how they can be utilized, while either by itself just left blanks.
At least for me)

-- 
jeske_at_uiuc.edu    + David Jeske(N9LCA)<A HREF="http://www.cen.uiuc.edu/~jeske/">
NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008
    User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) </A>