lkml.org 
[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 12:37    [W:0.661 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site