Re: RTEMS Driver Interface for Microwindows --- Proposal

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

First, I agree 100% with your comments. 

>
>Actually, I don't have many ideas, but I've got some questions and
>comments.
>
>1) I think it would be better to just make select() work with any
>device/socket.  Not that I have any ideas right now on how to implement
>this, but I do think that we should try to conform to `standard' API's
>wherever possible.  Could someone have a look at the RTEMS socket select
>code and the `real' select code from FreeBSD and see if it could be
>crammed into RTEMS? 


I agree. Maybe this should the goal for the next release of RTEMS.
For the coming release, we'd better off stick with what we've got.
A "real" select() would be the best solution.

> 
>Personally, I think that most or all uses of select are better handled
>in a multithreaded system by writing the code to use one thread per
>blocking descriptor, but I also realize that the existence of select
>would make porting third-party code easier.
>

Agree. But, people develop applications to many different OSes and
to RTEMS capitalize on those applications, it has to provide 
equivalent API calls as the ones provided by these OSes. 
select() it is a very important one.


>Or, since we've already added a non-standard API for I/O event reporting
>to the network code (SO_SNDWAKEUP and SO_RCVWAKEUP) could we add similar
>callbacks to the termios code?  This would be much less desirable since
>it adds even more non-standard calls to RTEMS, but might be simpler to
>implement than the full select operation.
>
>2) Since the network code is already using a couple of events, and the
>select() code (or reasonable facsimile thereof) might use more, should
>there be some kind of official statement that events 24 to 31 are
>reserved for RTEMS internals? 


This might be a important thing to do. The same for IO_CTL commands.


>
>That's what I was saying.  The driver routines use only the ospeed
>(CBAUD) value, not the ispeed (CIBAUD) value, so using just cfsetispeed
>will result in the driver using whatever value was in the CBAUD bits. 
>There's nothing wrong with the cf[sg]etispeed routines themselves,
>though.
>


That's why I think we should fix them. If we call them, and the 
drivers to nothing, it violates the expectation of the programmer,
and looks like a bug to me.

Rosimildo.