Re: Adding select() to termios file descriptors

["Rosimildo DaSilva" <rdasilva@connecttel.com>]

From: Eric Norum <eric@cls.usask.ca>
To: rtems-snapshots@oarcorp.com <rtems-snapshots@oarcorp.com>; Rosimildo
DaSilva <rdasilva@connecttel.com>; joel@oarcorp.com <joel@oarcorp.com>
Date: Wednesday, December 22, 1999 9:25 AM
Subject: Adding select() to termios file descriptors


>After a little more time to think on this, I've got a few ideas I'd like
>to present.
>
>1) There should be no changes made until after 4.1.0 is released.


I agree. We'll have more time to mature our ideas.


>2) The entire serial I/O mechanism should be torn apart and rewritten to
>more closely match the networking I/O system.  For example, the existing
>termios code has too many places where interrupts are disabled for too
>long and has too much code run in the context of the receive and
>transmit interrupt handlers.  Converting to a system similar to the
>network stack (one task for receive, one for transmit, protection via
>semaphores instead of interrupt disable, etc.) will fix these problems.


I must admit that I did not like all the "busy wait" stuff that I saw there.
I have tried to increse the size of the input buffer for one device,
and realized that is impossible without recompilation, and it would be
the same size for all devices.
Yes, termios needs a revision for sure.

I would suggest to come up with a more "controlled" model for
device drivers on RTEMS in general. Right now they have a very good
interface, but the semantic for read() and write() is totally open.

    + open(), close(), read(), write(), ioctl().

We need to "enforce" semantic for:

   + blocking/non-blocking mode
   + timeout for read and writes.
   + standard setup for these parameters
   + input/output buffers
   + etc.
   + kernel required ioctl() services x user defined ioctl().

I guess enforcing these rules to the device drivers, make the termios
just a wrapper around your device model.


>3) The new serial I/O mechanism should fit in with the networking code
>so that a select() can wait for serial and/or socket descriptors to
>become ready.

I guess it is doable.


>4) The new serial I/O mechanism should allow for multiple line
>disciplines to allow for efficient implementation of things like PPP and
>for supporting things like commandeering console I/O to a telnet
>connection for remote console operation (c.f. VxWorks).  The whole
>package begins to sound a lot more like STREAMS.....
>5) An application which calls select() but makes no other use of the
>networking code should not pull in all the rest of the network code.
>

This is a very important goal to be kept. Let's remember that
one important aspect of RTEMS is a small fooprint.


>Also, the sp and tm tests should be rewritten so they run even when
>interrupt-driven output is used since interrupt-driven output will be
>then norm once item (2) above is implemented.
>
>Comments?
>Anyone out there feel like taking on this project?


The migration path would be one interesting thing that
people might want to know early on, before they
commit any time on it.

Rosimildo.