Re: More VSTa info?

From: Andrew Valencia <vandys_at_nospam.org>
Date: Mon Aug 08 1994 - 10:32:02 PDT

[Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> writes:]

>A relatively small group. Are all of these people ones who were
>associated with the project from its inception?

No, people come and go. Of the core, one is an original bringup site. Two
others of the "outer dozen" were original bringup sites as well.

>> In features, it lacks many things which a "full" OS would obviously have.
>Anything in particular, or are you refering to the broad collection of
>utilities and features grafted onto systems as they mature?

There you go. For instance, right now I'm porting RCS. It uses %.*s format
for printf()'s--which wasn't there.

Actually, not a great example. When I wrote VSTa the BSD distribution was
under attack by USL, so I chose not to use it, nor any of its derivatives,
Now that it's in the clear, we'll probably switch to its use.

>Photon is a new product from Quantum Software.

Ah, I didn't recollect it by this name, although I saw Dan's posting about a
report on it being available. Yes, we're very much in line with QNX's
thinking on these things, except that they're proprietary. :-(

>> Far superior to Minix (1.1/1.2, I haven't looked at it since then). We use
>> the usual VM tricks. Comparable to QNX, although clearly their product is
>> far more finely tuned.
>What qualities make it superior to Minix? (Layman's terms please)

Simply, Minix uses copying because the 8088 did not have support for
anything better. I use page remapping, because I targeted 32-bit/virtual
memory processors.

>I also
>received a request from Dan H @ Quantum to cc any information to him. He
>is interested in the comparison of message engines particularly.

Please feel free to forward anything I write.

>MPI is
>a library based message system for heterogeneous system (I gather from
>reading comp.parallel.mpi). How would this compare to a kernel based
>system as implemented in VSTa?

The VSTa messaging engine is only intended to do local system moving of
messages. There are no hooks for placing networking code into the kernel,
and we don't really plan for the kernel to cause messages to flow to a
distant node via a networking protocol.

Instead, VSTa's messaging engine would simply be used to connect a client
with the local networking server, which would simply be another user-mode
task. Thus, instead of:

                        Machine1 | Machine2
USER Client1 | Client2
-------------------V------------------------------------^------
KERNEL Messaging->TCP/IP->Ethernet->TCP/IP->Messaging

I plan:

                        Machine1
USER Client1 TCP/IP Ether-> (to other machine)
-------------------V-------^-V----^---
KERNEL (Messaging only)

>Thanks for your reply. While I may not have anything to contribute to
>your project, congratulations on what you and your contributors have
>accomplished to date!

Thanks! I didn't write it with any idea of "beating out" Linux/FreeBSD/
NetBSD/what-have-you. Rather, I wanted a set of software on which the
various ideas surrounding "microkernels" could be explored. If you get
enjoyment in cruising through the current VSTa source, I'm very satisfied.
If you eventually contribute, so much the better!

                                                Regards,
                                                Andy Valencia
Received on Mon Aug 8 09:30:59 1994

This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:04:28 PDT