des@nsc.nsc.com (des) (02/15/89)
Hello,
I am a bit late, but here goes my two cents worth.
I am writing an ethernet driver for minix at the moment as part of the
TCP-IP port. In the process I have inspected the tty driver in a little
detail and am decidedly unimpressed.
First, too much time is spent with interrupts off. Too much time is spent
copying data around. Too much time is spent in message passing.
Anyway, as for interrupts. It appears that when an interrupt occurs the
following events occur:
1. Shut off interrupts
2. Save current proc's context
3. Call interrupt service routine (usually ends up building a
message to a task handler)
4. Reset 8259 (non-specifically)
5. Restore next proc to run
6. Reenable interrupts.
If I gathered correctly, ast wants the code "clean", by having the interrupt
controller written to in "one place". First, this does not happen anyway, i.e.
not all drivers leave up to interrupt(). Second, you can only go so far for the
sake of "pretty, simple" code. In the case of interrupts and device drivers, it
is far more important to trade off some "elegance" for performance.
I think each driver should do the following:
1. Mask out the specific (its own) interrupt in the 8259 imr
2. Re-enable all other interrupts (sti instruction)
3. Service its routine.
4. Mask out device int line, or reset it.
5. Issue specific EOI to 8259 (clr this chnl's bit in isr)
6. Re-enable device int line.
This can readily be done in assembler. And for those who don't like assembly
"dirtying up" the code, the gain in having other interrupts on far outweighs
the loss. One other point. The above steps are good practice to ensure the
8259 sees the next <edge> from the device interrupt line (steps 4,5,6).
And on another point, I think the restriction on no direct signalling from
user to kernel should be removed. This results in inefficient operation in a
networked environment. (Yes, I know amoeba is supposed to be good, but it
could work even better with less copying). The reason is that you really do
not want extra copying of data packets around, and the extra overhead of
having to go through FS just to do I/O. By having the IP driver do read/write
calls direct to /dev/ether I can move data direct from user to/from driver,
(as the tty line does), but without 2 extra messages (currently required to
pass through FS). The only problem with this is killing of a process. Am I
right in thinking that MM will have to send a signal to /dev/ether to kill
off a blocked process? (Actually in my driver I never block on reads to
/dev/ether, just return a no_data message).
Well, enough rambling on. Could someone please answer that question (the
one about MM signalling device driver's when killing off a process).
Cheers, and let's get the I/O performance of Minix up a bit. I will look
at Evan's code when I get TCP-IP running on Ethernet - maybe that is better
in terms of I/O latency etc.
Reply: des@logic.nsc.com
{decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!logic!des
Des Young, M/S D3635 National Semiconductor, Santa Clara
The light at the end of the tunnel was only a burglar's torch - J.Buffet.