Re: [Xenomai-core] Future of fusion
Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce ready to run kernel/Xenomai Debian packages. Well, quite frankly, I do not know much about the debian packages creation process, in any case not enough to do the work which remains to be done. The best I can do is add the debian directory to the svn repository, letting volunteers work on it and submit patches... I have proposed a few improvements for the Debian packaging in wish #4523: https://gna.org/bugs/index.php?func=detailitemitem_id=4523 -- Romain Lenglet
Re: [Xenomai-core] Future of fusion
Marco Cavallini wrote: Hello, I'd like to know (if is possible) the future plans and task schedule of fusion into xenomai project. Unless I don't misunderstand your question: Xenomai _is_ fusion. Take a look at the code base, the main difference between fusion-0.9.1 and current Xenomai SVN is the renaming (besides a lot of bug fixes). Regarding the roadmap: browse the xenomai-core archive, there were already a few postings about potential future directions. HTH Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Future of fusion
Marco Cavallini wrote: Hello, I'd like to know (if is possible) the future plans and task schedule of fusion into xenomai project. TIA There are things already going on under the surface right now, and others that would depend on everyone's input in order to start them or not. The roadmap will clearly depend on the combination of both aspects. I will give some details shortly about the current or next-to-be-started efforts, but the feedback part is important too, so here is the call for discussion once posted to this list: -- I propose that we start discussing along the following lines, going into deeper detail as needed, but in any case, please remember that we don't have infinite resources to do everything at once, and that we need to keep an organisation that fits our abilities to manage it, so let's keep it modest and efficient. If I missed some important issues, please jump in. After that initial work, we should be able to define a sensible roadmap. - Regular automated benchmarking: What is Xenomai currently capable of, how stable is it, do we progress or regress over time and releases, arch by arch? - Documentation effort, dissemination: I'm a potential new user, do I have some unambiguous source of information available to get my feet wet with Xenomai? - Architecture ports: There is life beyond x86. - Kernel ports: Is there still room for a 2.4 port? - Configuration, building and packaging issues: Could we make this easier? - Linux integration issues: Tools we should interface with, features we should make more seamless. - Scalability: Is Xenomai scalable enough? What's missing? - Drivers: Now that we have a deeply integrated port of RTDM, what's next? Field busses and other industrial gizmos anyone? - Current interfaces: Are we happy with them? - New skins: Any new colors for the chameleon? -- Philippe.
Re: [Xenomai-core] Future of fusion
On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: [...] - New skins: Any new colors for the chameleon? Perfect POSIX is, to me, more important than new skins. Perfect means, among other things, that the interference problem with the Posix thread library (libraries) under Linux is solved. What is wrong with the current implementation ? [...] But I assumed the interference with the posix thread library was solved. Could you elaborate a bit more on the issues you observed ? Well, if this problem is solved, I'm very happy :-) And maybe I look at the wrong places, but where do I find a succint explanation of the solution? Herman -- K.U.Leuven, Mechanical Eng., Mechatronics Robotics Research Group http://people.mech.kuleuven.be/~bruyninc Tel: +32 16 322480 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: [Xenomai-core] Future of fusion
Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: [...] - New skins: Any new colors for the chameleon? Perfect POSIX is, to me, more important than new skins. Perfect means, among other things, that the interference problem with the Posix thread library (libraries) under Linux is solved. What is wrong with the current implementation ? [...] But I assumed the interference with the posix thread library was solved. Could you elaborate a bit more on the issues you observed ? Well, if this problem is solved, I'm very happy :-) And maybe I look at the wrong places, but where do I find a succint explanation of the solution? Well, what's your question first? :o -- Philippe.
Re: [Xenomai-core] Future of fusion
On Thu, 13 Oct 2005, Philippe Gerum wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: [...] - New skins: Any new colors for the chameleon? Perfect POSIX is, to me, more important than new skins. Perfect means, among other things, that the interference problem with the Posix thread library (libraries) under Linux is solved. What is wrong with the current implementation ? [...] But I assumed the interference with the posix thread library was solved. Could you elaborate a bit more on the issues you observed ? Well, if this problem is solved, I'm very happy :-) And maybe I look at the wrong places, but where do I find a succint explanation of the solution? Well, what's your question first? :o Sorry if that was not clear. The question is: how is the following problem solved? Where the problem is as follows: using Posix threads in realtime requires another library than the standard NPTL library that Linux uses (at least, I think you require another library), but how do you make sure to link to the correct library? Or is NPTL realtime safe? Herman -- K.U.Leuven, Mechanical Eng., Mechatronics Robotics Research Group http://people.mech.kuleuven.be/~bruyninc Tel: +32 16 322480 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: [Xenomai-core] Future of fusion
Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: [...] - Drivers: Now that we have a deeply integrated port of RTDM, what's next? Field busses and other industrial gizmos anyone? That's an interesting avenue for all our machine control oriented realtime applications. But this avenue is full of incomplete or non-free specifications and interfaces... Indeed, but we cannot solve all problems at once. Let's start with those devices which are more or less open (and there are already a lot). Let's also try to propagate the message that RTDM is the prefered way to provide real-time drivers. And if someone comes up with a new driver, check if its interface is generic enough to implement it for similar devices as well (=generic device profiles). Far from being perfect, but there are first efforts for such profiles: Serial (as it comes with Xenomai), process image (see the Hilscher Interbus driver I once announced), or CAN (yet a bit in flux, but things slowly stabilises here). Plans exist to go the same way for low level access to FireWire or USB. And you can even map whole protocol stacks onto RTDM, like UDP/IP (RTnet) or also CANopen. The enables thrilling combinations without the need to rewrite your application. The interest in such progress is there, not yet on the vendor side, but on the user side - including many industrial users. And they can push things forward as well, finally making at least some vendors more cooperative, too. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Future of fusion
Hi Philippe On Thursday 13 October 2005 09:24, Philippe Gerum wrote: - Regular automated benchmarking: What is Xenomai currently capable of, how stable is it, do we progress or regress over time and releases, arch by arch? Have a couple of x86 development boxes running 24/7 - Could set one up as a compile farm for running automated builds. Also have a PowerPC thin client that I would like to utilise, but could really do with some help in setting up the tools for cross-compiling the base system under Debian. - Configuration, building and packaging issues: Could we make this easier? Anything that involves patching/compiling kernels is bound to cause trouble for new users. Perhaps some tests for kernel options known to cause trouble (such as APM REGPARM) that print out large warnings during the config stage might help.. Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce ready to run kernel/Xenomai Debian packages. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
Re: [Xenomai-core] Future of fusion
Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote: Herman Bruyninckx wrote: On Thu, 13 Oct 2005, Philippe Gerum wrote: [...] - New skins: Any new colors for the chameleon? Perfect POSIX is, to me, more important than new skins. Perfect means, among other things, that the interference problem with the Posix thread library (libraries) under Linux is solved. What is wrong with the current implementation ? [...] But I assumed the interference with the posix thread library was solved. Could you elaborate a bit more on the issues you observed ? Well, if this problem is solved, I'm very happy :-) And maybe I look at the wrong places, but where do I find a succint explanation of the solution? Well, what's your question first? :o Sorry if that was not clear. The question is: how is the following problem solved? Where the problem is as follows: using Posix threads in realtime requires another library than the standard NPTL library that Linux uses (at least, I think you require another library), but how do you make sure to link to the correct library? Or is NPTL realtime safe? Nope, that's why there is RT-NPTL. And that library is still in flux, especially now with the ongoing work on PREEMPT_RT. Let's wait for the result and see if it is feasible to reuse this userspace infrastructure. For now, I'm convinced that it is much more comfortable for the user to obtain kernel extension and userspace library from one hand with a clear and consistent versioning. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Future of fusion
On 10/13/2005 03:33 PM Philippe Gerum wrote: Paul wrote: Hi Philippe On Thursday 13 October 2005 09:24, Philippe Gerum wrote: - Regular automated benchmarking: What is Xenomai currently capable of, how stable is it, do we progress or regress over time and releases, arch by arch? Have a couple of x86 development boxes running 24/7 - Could set one up as a compile farm for running automated builds. That would be great, thanks. Let us know if we could help. Also have a PowerPC thin client that I would like to utilise, but could really do with some help in setting up the tools for cross-compiling the base system under Debian. What about DENX's ELDK? - Configuration, building and packaging issues: Could we make this easier? Anything that involves patching/compiling kernels is bound to cause trouble for new users. Perhaps some tests for kernel options known to cause trouble (such as APM REGPARM) that print out large warnings during the config stage might help.. Ok, I have something rather highly ranked on my TODO list (which ends up by 2117 or so), which is about allowing to build all Xenomai's in-kernel support statically in the Linux kernel. The rationale behind that is about making more straightforward and efficient embedded setups; straightforward because modules add more complexity than they would solve in typical embedded systems, and efficient since loading modules in a running kernel doesn't come for free. That would be great for embedded systems, indeed. Apart from getting rid of the module infrastructure, it also save TLB misses because modules are typically placed in vmalloc'ed space. Systems with small TLB entry tables will benefit, like PowerPC 8xx and 4xx. To do that, portions of the Xeno build system which are currently autoconfiscated should move to the target kernel, so that we would only keep the autoconf infrastructure for what it's good at, i.e. building the user-space support. The basic idea is that we would then have a kernel extension part either buildable statically or as modules using Linux's Kconfig/Kbuild infrastructure, and a user-space support package providing the various interface libraries, headers, tools and scripts, ala glibc. The immediate advantages would be: - The core of the Xenomai support would be statically embeddable in the Linux kernel; - No need for a Kconfig duplication like we have now; most of the options currently presented by Xeno's Kconfig sub-system concern the kernel portions, and very few actually concern the user-space stuff. We would then get rid of the former, and rely on the vanilla Linux's one instead. - Centralizing Xenomai's kernel-related options with Linux's ones would make easier defining sanity checks (e.g. APM stuff and so on), since we could use the Kconfig language to enforce them in order to obtain sane configurations by construction (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's Kconfig is not aware of the kernel settings, so the checks are performed afterwise by the configure script instead. - Removing the module compilation logic from the autoconfiscated Makefiles would be a significant simplification of the Xeno build system, and would make it less dependent on the kernel build system. - This build process is still fully automatable. - LKML people among my co-workers (Hi Stelian!) would start talking to me again, since I would stop pretending that autoconf is a sane way of controlling builds for kernel-based code. :o The way I see a typical build process would then be along these lines: $ tar jxf xenomai-* $ mkdir xeno-build cd xeno-build ../xenomai-*/configure --kernel=/usr/src/linux --some-option-only-for-uspace-stuff --prefix=install-dir (the configure script would then prepare the autoconf _and_ make the necessary links from the target kernel to the Xenomai source tree to connect the modules to the kernel's Kbuild/Kconfig infrastructure. $ cd /usr/src/linux $ make gconfig The user would configure his kernel, and all the kernel-based Xenomai stuff, as if they were standard drivers/extensions $ make the_kernel $ cd xeno-build make install And we would be done. Well, in a perfect world, I mean. Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce ready to run kernel/Xenomai Debian packages. I think we should be able to work this out will Gilles before 2.0 is out since it's a separate build-related issue. Regards, Paul.
Re: [Xenomai-core] Future of fusion
Herman Bruyninckx wrote: The question is: how is the following problem solved? Where the problem is as follows: using Posix threads in realtime requires another library than the standard NPTL library that Linux uses (at least, I think you require another library), but how do you make sure to link to the correct library? First, Xenomai user-space POSIX library uses the same data structure definitionss as Linux threading libraries (whether linuxthread or NPTL). This way, including Xenomai specific headers is not mandatory for using its POSIX library. Another advantage: Xenomai implementation of POSIX functions may decide to delegate control to the real ones without having to touch the user structures. Of course, if you do not include Xenomai headers, you will not get declarations of some functions specific to Xenomai, some of these functions are non portable (such as pthread_make_periodic_np and pthread_wait_np, which are still the easiest solution to get periodic tasks in primary mode), other are not yet in all distributions, such as the message queues API. Second, Xenomai build a user-space library made for use with the --wrap option of the GNU linker. Xenomai implementation of the pthread_create function is called __wrap_pthread_create, and when linking with Xenomai library, ld replace any call to pthread_create in the user code by __wrap_pthread_create, so that at run time, Xenomai implementation of this function gets called. This solution avoids the unexpected segmentation faults. Users mistake result either in linker errors (because of the use of a function of Xenomai which does not exist in Linux threading library without the --wrap parameters, or conversely because the --wrap option was passed while trying to link with one of Linux threading libraries). In the worst case, a user program may run as standard Linux POSIX threads application if he forgot the --wrap options, but this is easy to see, since /proc/xenomai/sched shows no real-time thread. Do not get me wrong, passing the correct arguments to the compiler is as easy as with any other skin; it is just a matter of calling xeno-config --posix-cflags andd xeno-config --posix-ldflags. Some examples are included in skins/posix/demos. The current implementaion of Xenomai user-space POSIX skin also allow Linux POSIX threads libraries functions to remain accessible aside Xenomai calls; for example, you may still create Linux POSIX threads by calling __real_pthread_create. Actually, now that I think about it, being able to access easily Linux calls aside Xenomai ones was a requirement among the most important in our view. Or is NPTL realtime safe? the accuracy example in skins/posix/demos should help you get an opinion on that point. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Future of fusion
Paul wrote: Hi Philippe On Thursday 13 October 2005 09:24, Philippe Gerum wrote: - Regular automated benchmarking: What is Xenomai currently capable of, how stable is it, do we progress or regress over time and releases, arch by arch? Have a couple of x86 development boxes running 24/7 - Could set one up as a compile farm for running automated builds. Also have a PowerPC thin client that I would like to utilise, but could really do with some help in setting up the tools for cross-compiling the base system under Debian. Actually, there are ready made debian cross toolchain packages at debian.speedblue.org Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce ready to run kernel/Xenomai Debian packages. Well, quite frankly, I do not know much about the debian packages creation process, in any case not enough to do the work which remains to be done. The best I can do is add the debian directory to the svn repository, letting volunteers work on it and submit patches... -- Gilles Chanteperdrix.
