Re: [Xenomai-core] [RFC][PATCH 1/2] real-time print library
Philippe Gerum wrote: On Sun, 2007-02-18 at 20:38 +0100, Jan Kiszka wrote: 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. Right, but your patch seems to focus on printf() so far, hence my argument. [Btw, glibc's snprintf() called from rt_vsnprintf() is likely going to compete for the file lock in the MT_SAFE_IO case, which might not be what you want, if you don't want to take the mode switch penalty upon contention]. Going through glibc's stdio/libio stuff is hell, but based on my current analysis (and also when considering what *snprintf does) it is highly unlikely that there is anything to compete for. All required buffers are on the stack or in user hand, and that MT_SAFE_IO lock you referred to is set to NULL. 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. I was primarily talking about calling printf() then rt_printf() (or the other way around), which would not give any guarantee about the output sequence. 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...) You would still have access to the __real_xxx counterparts anyway. 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. My point is different, and it goes beyond the printf() case. IOW, should a developer: a) have to verify whether rt_printf(), rt_vsprintf(), rt_vsnprintf() etc. exist in some API we would provide, and decide to use them in replacement of the original glibc calls, and understand the consequences about predictability if they don't. or b) have to verify whether printf(), vsprintf(), vsnprintf() etc. are documented as members of the calls Xenomai hardens when she happen to need them, and understand the consequences about predictability if they don't. In both cases, such developer _must_ know what he's doing anyway, in order to ask himself either one of those questions in the first place, so this is clearly not about telling people life is good because call shadowing exists, just breath and live cluelessly. It's whether you want them to use a specific API, or to use a hardened subset of the original one. I tend to prefer b) because: - I tend to find much easier to tell people you may use a subset of the API you already know, than you must use another API to access a functional subset of the API you already know. The fact that original symbols would just have to be prefixed by rt_ does not change this fact: it's another API. - when running Xenomai apps over native preemption, finding rt_* and As I said: rt_printf vs. printf is a good example where native preemption does not change the picture noticeably, where you want special services even if the kernel knows about priority inheritance in order to boost such complex printing jobs over others. non-rt versions of the same symbol would look preposterous, and the point about X3 is to allow people to move freely from one real-time layer to another (i.e. co-kernel to native preemption and the other way around),
Re: [Xenomai-core] [RFC][PATCH 1/2] real-time print library
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
Re: [Xenomai-core] [RFC][PATCH 1/2] real-time print library
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. 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: - 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. - 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. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC][PATCH 1/2] real-time print library
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
