Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!decwrl!csus.edu!netcomsv!mork!hasty From: hasty@netcom.com (Amancio Hasty Jr) Newsgroups: comp.unix.bsd Subject: Re: ASTs for device driver usage (was Re: COM driver and X11) Keywords: COM AST Message-ID: <#h9lp2g.hasty@netcom.com> Date: 10 Jul 92 06:01:43 GMT Article-I.D.: netcom.#h9lp2g.hasty References: <cproto.710554678@marsh> <9d8lvff.hasty@netcom.com> <13gn4pINNfmj@agate.berkeley.edu> Organization: Netcom - Online Communication Services (408 241-9760 guest) Lines: 53 In article <13gn4pINNfmj@agate.berkeley.edu> cgd@agate.berkeley.edu (Chris G. Demetriou) writes: >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...) In the case of VMS, I believe that it has internal ast like delivery mechanism. Additionally, the problem of bsd drivers running at a relative high IPL will also have to be solved. > > 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... If a general mechanism is well thought out it will also work for the rest of the drivers. And this business of being ugly. I think the current state of drivers is not very friendly in a time-sharing environment. <rest of text deleted> > >However, it's better than the other (wart-like) solution... > >comments? > >-- > Chris G. Demetriou > cgd@berkeley.edu > amancio