Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!ames!agate!agate!usenet
From: cgd@agate.berkeley.edu (Chris G. Demetriou)
Newsgroups: comp.unix.bsd
Subject: ASTs for device driver usage (was Re: COM driver and X11)
Summary: having the COM driver use ASTs would be ugly..
Keywords: COM AST
Message-ID: <13gn4pINNfmj@agate.berkeley.edu>
Date: 9 Jul 92 06:42:33 GMT
Article-I.D.: agate.13gn4pINNfmj
References: <cproto.710554678@marsh> <9d8lvff.hasty@netcom.com>
Organization: Kernel Hackers 'r' Us
Lines: 60
NNTP-Posting-Host: agate.berkeley.edu
hasty@netcom.com (Amancio Hasty Jr) writes:
>cproto@abel.cs.curtin.edu.au (Tibor Sashegyi) writes:
>>I think the driver should be really split into two parts. A lower
>>level driver which is handling the receive interrupts at a high
>>priority and a very short execution path. This part should write
>>received characters plus status into a circular buffer and then
>>cause some software interrupt to invoke the higher level driver
>>to do all the fancy TTY bits.
>>
>I am sick and tire of trying to make the com driver work, I arrived
>at the same conclusion as you. It will be nice if the rest of the
>set ipl and restore ipls in the system be balanced; also to lower
>the ipl of the disk i/o.
(as far as i know, i'm the latest person to pull a major hack on the
386bsd com driver... somehow i think determining who gets the next
crack at a part of the system is LIFO... 8-)
There are some significant technical and aesthetic problems with
getting the com driver to work as above (using ASTs -- and that's
really the only way to do it well...):
traditionally, ASTs are used only for forcing context
switching, and evoking the behavior described above in the
networking code (so that, for instance, you can get lots
of packets from the ethernet in a burst, without having to
call ip_input on each as they are received...)
now, the problem is this: the networking code is more or
less part of the standard kernel, while the com driver
(and device drivers in general) are *NOT*. to add an
AST especially for the com driver would be, well,
ugly, because it would violate the machine-independence
of most of the "kern" and "net" subdirs...
In my mind, the solution is this:
add an AST type for "device AST" -- which would be
dispatched to a machine-dependent handler, which would
then check which devices needed the AST, and call their
handlers.
the drawback of this is that there would be an extra level
of indirection in the entire thing, and it could make
some of the device driver/interrupt handler code a bit
uglier...
However, it's better than the other (wart-like) solution...
comments?
i'll try to get this done soon...
(so that hopefully it will make it into 0.1...)
Chris
--
Chris G. Demetriou
cgd@berkeley.edu
I'm not from the computer center, and I'm *NOT* here to help *YOU*!