[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you


    This sounds very very nice, almost unreal. Even for the USB modem /
    serial drivers it'd make them much simpler and cleaner.


    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....
    > --
    > ** ** ** +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
    > Please read the FAQ at

    Vojtech Pavlik
    SuSE Labs
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:37    [W:0.029 / U:9.264 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site