Date: Fri, 29 Sep 1995 19:01:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: deborah@microunity.com (Deborah Gronke Bennett) Cc: terry@lambert.org, freebsd-hackers@freebsd.org Subject: Re: spl'ing to a specific interrupt level Message-ID: <199509300201.TAA15937@phaeton.artisoft.com> In-Reply-To: <9509291809.ZM29816@gallifrey.microunity.com> from "Deborah Gronke Bennett" at Sep 29, 95 06:09:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Here is what I understand about the FreeBSD interrupt system: > (btw, my device is an isa device) > from isa_configure, via config_isadev_c, my driver probe routine is called. > If it succeeds, (id_alive is true) then some time later my attach routine > is called. Just before register_intr is called to add my interrupt > service routine to the proper level, INTRMASK is called to add my > irq level to one of tty_imask, bio_imask, net_imask or SWI_CLOCK_MASK. > (Which one depends on the keyword in my config line). > > My understanding of the splXXX routines is that you call them to block > critical sections which could somehow depend on each other - that's > why you have the classes of bio (disk devices), net (network) > and tty (serial devices). My quandry is that I don't want to block > anything else I don't need to - I just want a routine to call > to raise the spl level to my level (whatever I put after the "irq" > on my config line). Is my only solution in this case to call splsoftclock? OK, you're saying that your serail board driver code takes an interrupt, but you are not going to provide tty (cannonical processing) device entry points for it, you're writing everything from scratch, including all behaviours. If this is the case, you will either need to take the collision with one of the existing classes (relatively easy) or add another class (relatively hard, from a cursory look at the code). The block is there to prevent reentrance of the support routines called at interrupt level that aren't reentrant on another interrupt. If you are planning on using the tty cannonical processing, you will probably need to add in arbitration for the device. This will also include using the calling unit abstraction. I suppose it's possible that the serial device won't be used for tty I/O or net I/O. If not, you'll need to pick something close or add a class. My last choice would be to add a class. If I were to do that, my first impulse would be to generalize the adding of classes and modify the current class-using mechanisms to use the more general routine as well (potentially a lot of work). > So, to answer your question, what I want to do is not to prioritize > my device with respect to any other device - I just want a way > to block my critical sections. > > Am I making this any clearer now? Yes. I assume you can critical code your own sections, so the problem you face is that without a class, you don't get an interrupt and you don't like the existing classes because of the concurrency penalty for what will essentially be unshared code. The "correct" answer is "make a class". The expidient answer, as above, is to overload one of the existing classes. If you don't expect to be doing serial I/O except through the board, I'd think overloading the tty would be an acceptable thing. If the serial board is sensitive to other people blocking it, and you will be running X or some other control/monitoring system, then you should still be safe with tty, if you make sure to use a bus or PS/2 mouse (and deconfigure the serial ports to make sure). Otherwise, it's off to add a class. 8-(. David Greenman and several others have written multiport serial board drivers and would be a good source of information if they'll let you pick their brains. Good luck on the project. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509300201.TAA15937>