Re(2): VSTa news

mato@kotelna.sk writes:
>
>Great! I look forward to many great undertakings. I unfortunately have not
>been active on the VSTa front for ages now so I wont make any promises.
>However I would like to ask if you are planning to work on any
>driver/network stack glue libraries that would allow us to pull drivers
>and
>TCP/IP out of *BSD? This is still something I would really like to do, but
>in the mean time anyone else interested in doing some hacking, go to it! I
>think this would be a most worthwhile project for someone wanting to get
>involved.

I would like to take a look at the xkernel
(http://www.cs.arizona.edu/xkernel/ ). This is a protocol framework that
includes many modularized components taken from the BSD code, including
TCP/IP. The protocols may be implemented asynchronously or synchronously
using in-process cooperative microthreading. Another VSTa-ish protocol
framework is netgraph (recently integrated into FreeBSD). It's a much
simpler design, using asynchronous-only components, running in a single
address space (the kernel, but it could be run anywhere). It provides PPP
as well as a host of other more arcane protocols that can be assembled
into any configuration at run time.

One thing that I think would benefit VSTa would be a way to abstract the
message passing functionality so that the focus can be placed on writing
components without commiting to a server/process. For example, TCP and IP
may be seperate components (as they are in xkernel), but the system could
load them into the same address space as one process rather than two.
Similarly, if you are running a single filesystem on a single drive (with
both the driver and the fs running as the same user), the system may well
load the fs code and the driver code into the same process, saving a layer
of unnecessary message-passing overhead. The idea is that the code would
remain the same whether the processes are shared or not. That way, the
system can figure out the most efficient way to link the components
together at run time. Of course, if the user wants to do something
strange, like run the driver on one machine and the fs on another, it can
always drop back to old method and use the message passing syscalls.
Received on Tue May 16 09:26:59 2000