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

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

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

Philippe Gerum wrote:
> On Sat, 2007-02-17 at 18:43 +0100, Jan Kiszka wrote: 
>> Philippe Gerum wrote:
>>> On Sat, 2007-02-17 at 10:02 +0100, Jan Kiszka wrote:
>>>> 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.
> 
> You seem to be talking specifically about a (non-intrusive) trace
> logging feature, rather than plain printf() then, because the latter
> does not make much sense to be used in a real-time scenario unless the
> caller does accept to pay the price of running a complex operation
> anyway.

No, I'm also talking about plain printf scenarios from hard-RT threads.
There is a difference between just doing a fairly simple snprintf to
format the output and going into the kernel to write it to some console,
file, network link, or whatever.

> 
> If, on the other hand, you want to provide more efficient replacements
> of existing standard routines in terms of performance, then those should
> bear the standard names. Otherwise, people would start mixing printf()
> and rt_printf() in their application [experience already showed us that
> it's inevitable], and for instance, you would start receiving complaints
> about inaccurate output order, leading to incorrect interpretation of
> traces, because both implementations would obviously rely on distinct
> internal buffers.

I agree that there is an ordering issue when writing to stdout or stderr
/wrt to standard glibc routines. But the question is where to draw the
line. We surely do not want to redirect each and every file write to a
server thread _automatically_ (would be quite a performance PITA...)
just because some fprintf may otherwise happen to come out in an
unexpected order. We cannot avoid that the user has to be - to some
degree - really _aware_ of what (s)he's doing.

> 
>>> - 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.
>>
> 
> And that would already be enough to explain why we would not want to ask
> people to stuff their Makefile with LDFLAGS += -lrt_printf -lrt_malloc,
> IMO. Because after a few years, my feeling is that the LDFLAGS would
> grow out of any reasonable proportion, and our maintenance burden the
> same way.

So your point is single vs. multiple rt-helper libs? I don't see a
problem bundling fairly small services (a few kB) into a single lib,
common to all skins. But once it takes a bit more to provide a certain
service, we have to keep memory-restricted embedded applications in
mind. Configuring features at build time is one way. Providing
reasonably clustered libraries is another. Hard to draw a line now
without having all components already at hand or at least in mind.

> 
> I would also consider things like stdio in general, not just printf, by
> mean of server thread(s) the way you did it. Being able to send/receive
> a file stream without resorting -at least explicitely- to a proxy thread
> would simplify a bunch of existing applications for instance.

Yeah, the way rt_printf writes out data might be extended to a common
pattern also for other stdio output services. If async stdio-like
reading is also worth providing in a generic way is something I would
like to see backed up by concrete application scenarios. Maybe.

> 
> Aside of purely ANSI services, there are some POSIX/SVID calls which are
> not relevant to libpthread_rt, but for which a hardened counterpart
> would make sense over a co-kernel, like SunRPC (over RTNet's UDP, that
> is), syslog routines, random, or libcrypt members for instance.
> 
> My point being that we cannot anticipate the exact list of features we
> would want to harden in the future, but we do know already that
> applications ported/created over Xenomai are always more complex, so we
> will likely need more of those features. Componentization must have a
> limit, and my guts feeling is that going for a specific API for each and
> every feature would lead to maintenance chaos and user confusion.
> Additionally, sharing internal routines common to those features would
> be possible with a centralized architecture (unless we go for
> yet-another-library exporting those routines).

Well, would you be more happy if we call the printing library
libstdio_rt without yet implementing all the related services, but
pointing out the potential path of this lib in the future?

> 
>>> - 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.
>>
> 
> IMO, the only way to make "explicit real-time programming" a rule is to
> disable all access to real-time unsafe calls, i.e. basically to the
> glibc, and this is obviously something we don't want to, because this
> would contradict the fundamental goal of Xenomai toward integration
> within the regular Linux programming model.

No, disabling such access is surely a no-go. But I really think we
should strengthen the mode-switch detection, maybe be considering to
invert its default (always or just for debugging). Mode-switch detection
by the user space tracer could be a first step in this direction
(without immediately breaking the API).

> 
> Because of this, that's a fact of life that users are most often going
> to consider that a commonly used glibc routine they need is real-time
> safe enough to be used until proven wrong (*), instead of suspecting
> such routine to be unsafe a priori, and looking for a safe replacement
> in some specific API we might provide (this is why we all had to warn a
> number of people countless times on the list about their use of printf()
> in deemed time-critical sections from various pieces of code they showed
> us).
> 
> This is also the reason why I still think we should "upgrade" the
> commonly used standard routines to be real-time aware by gradually
> providing hardened replacements for them, not trying to convince people
> about the fact that using standard routines might not be the right
> solution to common problems in the real-time case.
> 
> (*) actually, the real problem is that some users might think that we
> are smart enough to make deterministic and efficient code out of any
> regular Linux service they might think of, albeit the founder of the
> Xenomai project might be a total bonehead. Oh, well, anyway...
> 

As I said, overloading, just trying to shadow the differences doesn't
solve the problem automagically. You often need special configuration
APIs for the shadowed one, thus you need understanding of its
mechanisms. And you need access to the original functions because of
drawbacks of the hardened variants (if they had none, we could just
submit glibc or whatever patches...).

Overloading is only as long comfortable as you _mostly_ make use of the
replacement services in your application. Once it is the other way
around, this automatism becomes quite a PITA. We luckily already have
two programming models with POSIX vs. native skin matching both use
cases, and I consider this a strength, not a weakness of Xenomai.

Granted, alternatives can cause confusion, and we may have to improve
beginner guides on the homepage or wherever to underline and explain
these differences more explicitly.

Jan


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