Re: Is tty->receive_room no longer usable w/ SMP?

[Peter Hurley <peter@hurleysoftware.com>]

On 02/13/2014 01:50 PM, Grant Edwards wrote:
> On 2014-02-13, Peter Hurley <peter@hurleysoftware.com> wrote:
>> By "support", do you mean "add new features" or "workaround hardware
>> bugs"?
>
> Both.  "New features" mostly meant support for new models, but there
> were also some actual new features and fixes for old ones that didn't
> work.  For example, it turns out almost nobody on the planet uses
> IXANY. It got left out of both our automated and manual regression
> testing, and (embarassingly) it took 10+ years for somebody to realize
> that it didn't work.  And that "somebody" was a customer that still
> had 2.4 kenels running in production machines.

Not unusual. The N_TTY ldisc just had a bug fixed in 3.10 where turning off
IXON with an already-stopped tty permanently hung the tty.

>>> For another driver, it's still a tty driver because the serial-core
>>> API just didn't fit the device well enough to make it work.  One
>>> issue I recall is that our driver for that device needs to be able to
>>> cause specific error returns for write() calls that are made when the
>>> hardware is unavailable (and I think there are different errors
>>> depending on why it's unavailable).
>>
>> And this is the driver that uses tty_flip_* interface directly?
>
> Well, they all do (under some circumstances). AFAICT, the method
> provided by serial core is uart_insert_char().  When we initially
> moved from tty driver to serial driver, we did everything in the
> simplest, most obvious way (e.g. uart_insert_char()).  But we moved
> away from that for performance reasons.  Our hardware is optimized for
> transferring data to/from continuous buffers using 32-bit bus cycles
> rather than reading/writing characters one at a time.  At one point in
> history our drivers would use inline assembly to execute a single
> machine instruction to write an entire block of tx data to the
> hardware or read an entire block of data from the hardware.  There
> were also some prototypes that did bus-master DMA for rx/tx data, but
> that turned out to be more overhead than programmed I/O, and it was
> abandoned.  Now that CPU speeds have increased so much faster than bus
> speeds, the inline assembly is no longer needed, but making a function
> call for every rx byte is still enough to use an alarming amount of
> CPU time.

We should extend the serial-core to add rx methods that work
with your UARTs in their fastest and most native way. The idea behind
serial-core is only to abstract the busy-work away from the i/o, not
become an ill-fitting shoe that enforces The One True Way.

Regards,
Peter Hurley