Re: list archived and other (newbie) questions

From: Andrew Valencia <vandys_at_nospam.org>
Date: Mon Aug 30 1993 - 08:25:06 PDT

>Is there an archive of this list ?

Not that I know of... I collect stuff from my inbox, but I don't
record what I write.

>Is there any co-ordination - who is doing what ?

I guess I'm the coordinator, rather by default.

>Is there a consensus on priority items ?
> - SCSI / Shared Libs / More HD support / SVGA / Networking / ...

There's a shared library mailing list (vsta-shlib@amri.cisco.com).
Several folks have shown interest in SCSI support, although to the
best of my knowledge nobody is writing code yet.

My "Tenex" filesystem is written and I'm in the process of bringing
it up. Nick has a bitblt server running. I am not aware of any
other specific development--please mail me or post to the list if
you're doing something!

>I agree, servers should provide mechanism not policy, however
>X is an ungainly bloated beast.

One of our folks is writing his own window system from scratch, with
some inspiration from Plan 9's windowing system. I expect he'll be
posting regarding this soon.

>VSTa is intended to remain multi-platform.

It has only been ported to one platform. Yes, I tried to abstract
out the machine-dependent parts.

>ISA bus architecture is a dog.

Let's avoid simple religion and flames. I have gotten entirely too much
practical work done using this architecture to write it off. Yes, it is
frayed around the edges. It's cheap, fast for the price, and it happens
to be what I ported VSTa to first because of this.

>Is there a need for bus/BIOS/IO-port scanning in more than one program ?

We don't use the BIOS; everything is native 32-bit. Coordination is
done from the individual driver programs (each its own user-mode
process) via registry for IRQ and DMA vectors. There is also a level
of coordination provided by the namer registry for port values. There
is no central, monolithic autoconfig program. In fact, individual
drivers can be started and stopped as the OS runs.

I envision SCSI support as being broken into the adaptor-specific part
and then the SCSI command set-specific part. Each would get its own
process. Thus, the same SCSI disk code would run on top of servers for
Adaptec or Ultrastor adaptors. I would guess that the adaptor server
would provide hints concerning what SCSI addresses on his bus were
occupied.

                                        Andy
Received on Mon Aug 30 08:30:08 1993

This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 19:37:12 PDT