Any users of the Termios receive/send callbacks?

Chris Johns chrisj at rtems.org
Mon Mar 20 23:57:19 UTC 2017


On 20/03/2017 20:47, Sebastian Huber wrote:
> On 20/03/17 10:38, Pavel Pisa wrote:
>> Hello Sebastian,
>>
>> On Thursday 23 of February 2017 07:51:13 Sebastian Huber wrote:
>>> >Hello,
>>> >
>>> >the RTEMS Termios implementation provides receive and send callbacks:
>>> >
>>> >https://git.rtems.org/rtems/tree/cpukit/libcsupport/include/rtems/termiosty
>>>
>>> >pes.h#n41
>>> >
>>> >There is no API to install these callbacks. They are not used in the
>>> >RTEMS code base. Is there someone how uses this stuff? I would like to
>>> >change the invocation conditions to use them for the poll(), select()
>>> >and kqueue() support.
>> it would be great. Would it work with bare RTEMS or libbsd
>> would be required? If it can be used without libbsd
>> on memory constrained systems then it would be great.
>
> I already checked in the poll() and select() support for Termios in
> libbsd. The poll() and select() functions are a part of libbsd. They use
> the sleep/wakeup support of BSD which in turn uses a hash table of sleep
> queues. This is indeed a problem for memory constrained systems. I think
> with some work it might be possible to provide a low memory footprint
> configuration of libbsd, however, I don't have time/budget for this.
>
> There are some fundamental problems with the RTEMS Termios
> implementation to fully support POSIX Termios, e.g. input processing is
> mostly done by the reading task (e.g. echo). One option is to use the
> Termios support of FreeBSD with the low level drivers of RTEMS to fix this.
>

I am a little confused by this and what we are attempting to do here.

Why would someone want 'select' or 'poll' on a memory constrained 
system? I understand in the context of libbsd it allows us to bring 
existing code onto a board. Is this also a requirement for memory 
constrained systems?

The other aspect is how we document and explain "Termios for RTEMS" if 
we have two differing implementations where code may not be portable 
between a libbsd build and a non-libbsd build, ie legacy networking? For 
example I have a large project that can can be built with the legacy and 
libbsd networking stacks. If the libbsd termios is a better 
implementation then I see no problem but it is not clear to me if this 
is the case.

Chris


More information about the users mailing list