Messages in this thread | | | Date | Tue, 22 Aug 2000 14:38:52 +0200 | From | Vojtech Pavlik <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
Hi!
This sounds very very nice, almost unreal. Even for the USB modem / serial drivers it'd make them much simpler and cleaner.
Vojtech
On Tue, Aug 22, 2000 at 02:16:51PM +0200, Rogier Wolff wrote:
> It is not quite that bad. > > We need an architecture similar to the net devices. > > tty layer just need a few callbacks. > > The tty layer needs to set termios, and write characters. tty layer > should copy these into the circular buffer without leaving that to the > individual driver. (*) Usually the interrupt routine will just empty > the circular buffer. > > The serial driver needs to report "here is another char". That might > be an inline function. > > The serial driver also should be able to report "here is a bunch of > chars in IO memory". There are a few more possibilities. > > Initial implementation of the improved tty layer may implement that > the trivial way, but it can be enormously optimized almost trivially > too. > > Now, currently, most of the recieve handling is postponed to the > bottom half. I question the usefulness of this optimization. It > certainly adds latency. What is it that needs to be done on reception > of a few chars? Copy the data to userspace, and hit the waitq of the > process that's waiting for data. If you want to prevent the races, use > a kernel-space circular buffer, and do the processing (copy to > userspace) in the context of the wokenup process. > > Similarly, a line discipline like "ppp" will just scan the chars for > the end-of-packet char while copying the data to the reception skbuf. > It's not as if this is highly time-consuming: we already have to copy > the data somewhere, so that part is "unavoidable". And the possibly > more expensive part is the "packet recieved". We already call that > from the interrupt routine many more times per second for the 100mbps > ethernet cards. > > Oh, with DCD and stuff, we also need a callback for "modem signals > changed". What to do with that (i.e. unblock someone in open, or > hangup the users shell) should be the tty layer's choice. Not > something that is done in the hardware driver. > > A driver would implement: > > open /* Just the bare "tell the hardware we're now > interested in various things like CD. */ > close /* nobody interested anymore. Disable interrupts > for this device. */ > get_modemsignals /* report the modem signals */ > set_modemsignals /* Set the modem signals */ > > tx_buffer_nonempty /* Call to use when tx buffer becomes > nonempty */ > change_termios /* termios changed. returns termios settings NOT > implemented in the hardware. */ > > and performs callbacks from the interrupt routine for: > - reception of characters > - modem status change > > Getting a callback for a modem status change (e.g. CD dropped) while > that is currently ignored is not a problem. This doesn't happen that > often. > > tx_buffer_nonempty will, on some chips (e.g. 16550 and compatible) > just enable tx buffer empty interrupts. On others it may have to push > a buffer full of data onto the card (for example, sx doesn't interrupt > for tx_empty unless the buffer was previously filled). > > The standard open routine will all the open routine followed by > set_modemsignals to set rts/dtr. Next, get_modemsignals is called to > check for DCD. > > This certainly CANNOT happen for 2.4, and it's a lot of work to get to > the level that we currently have with the current structuring. > > generic_serial is a step in the right direction, but it certainly > isn't the best way to do things. > > Roger. > > > (*) Just like filesystem or device drivers change file->ops to point > to their own "ops" structure, that is what a "super intelligent" > serial driver would do if it didn't want the automatic "write copies > into circular buffer". Or we could have a write routine anyway, which > most drivers wouldn't implement as they wanted the fallback > copy-to-circular buffer.... > > -- > ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > * Common sense is the collection of * > ****** prejudices acquired by age eighteen. -- Albert Einstein ******** > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |