Driver design question

[Jonathan Shapiro]

   [With multiple kernel stacks... ] you [still] need to make proofs
   about the kernel running out of storage.

Agreed.  The only point of having stacks for the drivers is to
simplify the algorithms a bit and enable them to be scheduled by the
conventional mechanism.  The introduction of multiple stacks certainly
doesn't change the constraints any.

   Why are all the device drivers in the kernel?  (IMO device drivers are evil
   and should be treated with great suspicion...)

Humblest apologies! I was referring solely to disk drivers.  Actually,
I tend to assume that EROS has no other drivers to speak of (perhaps
tape drivers), and therefore spoke more generally than perhaps I
should have.

On the x86 family, a couple of other minimal drivers probably will
need to be in the kernel because the architecture cannot context
switch to save it's life.  In particular, the following are a concern:

1) Many x86 machines use the 16450 UART, which lacks an input
silo. You get an interrupt per character.  Newer/more expensive
machines tend to use the 16550 (or equivalent) which has (if memory
serves) a 4-character silo.  With a 16450, however, you are pushing
matters to try to sustain a 19.2 kbaud link.  The minimum interrupt
latency in the hardware is just too high.

2) For the same reason, it will probably prove useful to place some of
the segmentation and reassembly mechanism in the kernel for high-speed
networks.  The issue here is also context switch time, and for our
experiments at Penn we expect the network to be an issue under the
best of circumstances.  If it isn't, we'll have to write more
aggressive applications :-)

   >To start a disk I/O, the kernel queues the I/O request...

   I would think you would want to have a queue of pending work which is
   checked by the controller thread when it is not busy doing something else. 

Exactly. In addition, this lets the disk "thread" be scheduled like
any other thread, which is useful for real-time support, particularly
if we build a rate-monotonic scheduling class.

   All the more reason to have it [the driver] run in a domain.

Are there any thoughts on how to run a disk driver in a domain?  There
would seem to me to be a chicken and egg problem with this.  The only
way I could think of was to reserve some CDA ranges for such things,
mark them as non-checkpointed, and build them into the kernel image.
Otherwise, the disk driver soon gets swapped out...



Jonathan