Re: [Xenomai-core] [RFC][PATCH 1/2] real-time print library

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3666 bytes --]

Philippe Gerum wrote:
> On Sat, 2007-02-17 at 10:02 +0100, Jan Kiszka wrote:
>> This is a stand-alone real-time library for printf services. It is
>> embedded into the Xenomai user space part but actually doesn't depend
>> on any Xenomai service, just using plain Linux POSIX.
>>
>> The librtprint API looks much like the printf(3) man page:
> 
> [...]
> 
>> Further features:
>>  o Explicit or on-demand thread buffer creation
>>  o Override of default buffer size and polling period via environment
>>    variables ("RT_PRINT_BUFFER" and "RT_PRINT_PERIOD")
>>  o Support for buffer names (useful for the following patch e.g.)
>>  o Target output stream can be specified for each print invocation
>>  o Breaks all builds except for x86 (missing ubarrier.h headers) :o)
>>
> 
> ubarrier.h is redundant. include/asm-*/atomic.h is already there for
> such purpose.

Guess you mean Xenomai's atomic.h, not the kernel ones. I didn't
realised that it is also used from user space already. OK, will #define
something like xnarch_rmb/wmb (or xnarch_read_memory_barrier?) in that
file instead.

> 
>> The code is stuffed into src/rtprint for now as patch 2/2 will need this
>> lib to be built before the skin libraries. Better suggestions are
>> welcome though.
> 
> I basically agree that we need to provide more
> co-scheduler-based-rt-safe services, so a non-intrusive print out
> support should be welcome. A few things more:

Actually, rt-safe printing is independent of co- vs. native scheduling.
Even with a fully preemptible kernel, the worst-case complexity of
normal printf may not be acceptable. I think rt_printf is generally
useful in real-time programs.

> 
> - looking beyond print out, we will probably want to iron more ANSI
> services in the future. In order to prevent API proliferation, let's
> consider the hardened print out support as the beginning of some
> libansi_rt service collection.

I was already considering to include the TLSF memory allocator for
real-time malloc/free into some Xenomai library, but there were still
technical issues with its lacking 64-bit support e.g., preventing some
quick-hack.

What further services do you have on your radar? My impression is that
there will not be a lot beyond printing and memory allocation.

> 
> - the same way libpthread_rt shadows 1003.1c services to iron them over
> a co-scheduler, we should do the same for the ironed ANSI services. In
> that sense, there is no need for rt_printf, rt_vsprintf and so on, we
> just need to shadow printf, vsprintf and friends the same way we did for
> pthread_create and such for substituting the 1003.1c support. Again, API
> proliferation, especially of non-orthogonal stuff, needs to be fought
> now. The bonus is that we would not have to ask people to rely on crufty
> preprocessor tricks in order to compile their code in either real-time
> layers X3 is going to provide (i.e. I-pipe-based co-scheduler and native
> preemption). This would be consistent with the all-time Xenomai's
> mantra, i.e. "integrate as seamlessly as you can, don't get uselessly
> peculiar".
> 

Think of RTDM: we have transparent overloading with the POSIX skin, but
all others use the explicit selection via rt_dev prefix. I forgot to
mention this, but my plan was to apply the same pattern for librtprint
services.

I don't think we should overload every printf outside the POSIX skin's
scope automatically. Well, at least for the native skin, which is in my
opinion quite a lot about _explicit_ real-time programming, I would
really prefer to keep it like it is even under Xenomai 3.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]