Date: Sun, 1 Oct 95 14:24 PDT From: pete@puffin.pelican.com (Pete Carah) To: hackers@freebsd.org Subject: Re: spl'ing to a specific interrupt level Message-ID: <m0szVsL-0000ReC@puffin.pelican.com> In-Reply-To: <199509300201.TAA15937@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry writes: ..... >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. Some serial boards are specialized things that don't use any of the (existing) support routines - e.g. MPEG stream readers... [For this one 'net' is the most logical meaning but using it could impact performance of the ethernets if one held off int's too long.] They have to provide all interrupt and support code and it would be nice to not intersect with unnecessary classes (though if the hold-off time is short almost any existing class will do - I've taken tty since this machine needs good net performance too). Didn't know that slip 'or's net and tty. I'll take slip and ppp out of the config for the machine that doesn't need it then. (or is this 'or' not static in the masks and results just from spltty() code calling splnet() logically 'or'ing them?) >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). I've used tty so far. >The block is there to prevent reentrance of the support routines called >at interrupt level that aren't reentrant on another interrupt. Hopefully anyone who dares to write a device driver knows this; if not they are in *serious* trouble. >> 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. As in our case; the console is rarely used too (mostly remote, though pty's use spltty() too (looks like they call it directly only in select(), though)...) >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). Though PS2 mouse interacts unacceptably with the keyboard driver at the moment; I manage to force a reboot several times per hour by killing the keyboard on my one ps2-mouse machine, just by moving the mouse too fast. I suspect that spl won't help and one has to integrate the psm driver into syscons/pcvt to avoid bit-map overlap problems on the keyboard control port (or am I reading this problem right?) Might a shared global of the current contents of that port (or ports?) cure the problem? >Otherwise, it's off to add a class. 8-(. Making that easy would be nice for those of us doing industrial-control or other specialized type systems... The necessity for config knowing all the valid classes could be eliminated by using a phrase for the class (e.g. "spl tty" or "spl net") as is now done for most other device config variables. Then the classes could be passed into the kernel make in a .h file to be munched by something at the time of (presumably before, since assym needs the classes) mkassym or such. This would complicate the macros spltty() some since that header would be dynamic (or would more macros and a split call like spl(tty) be better?) IEEE 488 and its various serial equivalents are examples of things that would fall into their own class (and a system could easily have more than one of them so the class would have to be a real class). There are several 422 industrial busses that use regular tty boards but don't need protection from regular tty processing since they are always used in raw mode. Maybe an raw-mode-only driver and another class could be useful for this case? -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0szVsL-0000ReC>