Re: [Xenomai-core] Dev branch 2.1
Philippe Gerum wrote: Hannes Mayer wrote: Ciao Philippe! prepare-kernel.sh works well - I'd suggest to ask the user for the 3 needed parameters, instead of supplying them as parameters. e.g. # scripts/prepare-kernel.sh Linux directory: [default: /usr/src/linux] : Adeos-patch: [default: none] : Architecture: [default: i386] ...or something like that. Yep, good idea. ./configure also went well, but then: # make Making all in src make[1]: Entering directory `/usr/src/xenomai-2.1/src' Making all in include make[2]: Entering directory `/usr/src/xenomai-2.1/src/include' make all-recursive make[3]: Entering directory `/usr/src/xenomai-2.1/src/include' Making all in asm-uvm make[4]: Entering directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[4]: stat:system.h: Too many levels of symbolic links make[4]: *** No rule to make target `system.h', needed by `all-am'. Stop. make[4]: Leaving directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xenomai-2.1/src' make: *** [all-recursive] Error 1 /usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h Try building out of the source tree; it's something I'm likely going to enforce anyway. I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). Thanks. Wolfgang.
Re: [Xenomai-core] Dev branch 2.1
Wolfgang Grandegger wrote: [...] I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). If I remove the sym-link and copy .svn/text-base/system.h.svn-base to src/include/asm-uvm/system.h it compliles: muon:/usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h muon:/usr/src/xenomai-2.1/src/include/asm-uvm# rm system.h rm: remove symbolic link `system.h'? y muon:/usr/src/xenomai-2.1/src/include/asm-uvm# cp .svn/text-base/system.h.svn-base system.h OK, so far so good. The ipipe kernel boots, I've got a directory /usr/xenomai/ with all accustomed directories, but no modules... Wolfgang, do you have the e.g. xeno_native.ko somewhere ? Best regards, Hannes.
Re: [Xenomai-core] Dev branch 2.1
Hannes Mayer wrote: Wolfgang Grandegger wrote: [...] I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). If I remove the sym-link and copy .svn/text-base/system.h.svn-base to src/include/asm-uvm/system.h it compliles: muon:/usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h muon:/usr/src/xenomai-2.1/src/include/asm-uvm# rm system.h rm: remove symbolic link `system.h'? y muon:/usr/src/xenomai-2.1/src/include/asm-uvm# cp .svn/text-base/system.h.svn-base system.h OK, so far so good. The ipipe kernel boots, I've got a directory /usr/xenomai/ with all accustomed directories, but no modules... Wolfgang, do you have the e.g. xeno_native.ko somewhere ? The Xenomai nucleus is now intergrated into the Linux kernel and if you have selected static linking, no modules will be generated. Have a look to the Xenomai kernel options (using make memnuconfig and friends). Wolfgang.
Re: [Xenomai-core] Dev branch 2.1
Hannes Mayer wrote: Philippe Gerum wrote: [...] The surprise is that xeno_native is statically built-in by default. You can change that selecting the proper tristate position in the kernel config for the native skin. So everything (even the 16550 driver) is compiled in by default ? I didn't look that closely last night - I like that! No more insmodding :-) I just tried two of my programs, but each says: Xenomai: native skin or user-space support unavailable. (did you load the xeno_native.ko module?) kern.log says: I-pipe: Domain Xenomai registered. Xenomai: hal/x86 started. Xenomai: real-time nucleus v2.1 (Surfing With The Alien) loaded. Xenomai: starting native API services. Xenomai: starting RTDM services. What am I missing ? The feature set between user-space and kernel support is likely mismatching. Try passing --enable-x86-tsc to configure. More explicit messages will be printed out in later versions since we do have appropriate return codes passed back internally to distinguish the cases. Thanks and best regards, Hannes. -- Philippe.
[Xenomai-core] Dev branch 2.1
A dev branch toward v2.1 has been created. It features a new build system so that Xenomai now follows a split source model, decoupling the kernel space support from the user-space libraries used in accessing the former. It's work in progress, and there is still a lot of things to be done in order to finish the transition from a tightly coupled source-based system to the decoupled ABI-based model, but a lot has been done already. What remains is basically a slew of details to be fixed, since I had to somehow disconnect a number of things before attempting to connect them back gradually. All in all, my perception of this beast is that it's way simpler than the older fully autoconf-based system which tended to become overly complex over time. How does this work? Simple and easy. The Xenomai distro now comes with a pure kernel source part (ksrc/) and a pure user-space source part (src/). A few symlinks are made from the target kernel to the ksrc/ tree, so that Linux's Kconfig/Kbuild just sees Xenomai as a regular set of mainline drivers/extensions. A shell script (scripts/prepare-kernel.sh) automates the kernel preparation so that it eventually includes the Xenomai support. The user-space side is autoconfiscated, and only builds the interface libraries used to issue Xenomai syscalls, and the UVM libraries; period. The HAL has been made a static part of the kernel, since it has an architecture-dependent section, is totally silent when the nucleus does not use it, and weigths less than 10 Kb on any platform. Additionally, if something goes wrong into the HAL, well, there is little chance one is going to be able to unload it, fix it and try it again. Under such circumstances, the box almost certainly went out of the window anyway, so providing for the modular form is just, mhhh, braindamage. The simulator will be shipped as a separate tarball starting from 2.1. It is still part of the dev trunk though. Advantages: - The user-space support does not have to know about the target kernel. A set of features required by the former is just checked for availability when an application binds to a skin built in the latter. This ABI separation is going to be enforced; the idea is plain simple: I see absolutely no reason why user-space Xenomai interfaces should have for the RT applications a different role than the glibc has interfacing them to the regular kernel services. - Normally, no kernel headers are included anymore from user-space programs. This should solve the C++ issues in the same move. If some mistakenly remain, we will have to fix them. - The nucleus and all skins can be either compiled as modules, or statically built into the kernel (a glitch remains with POSIX due to a redefinition of sem_init(), but this is going to be fixed). - Binary packaging should be made simpler. - Xenomai actually looks like a more seamlessly integrated extension of the Linux kernel, since the kernel space is fully under the control of the vanilla Kbuild/Kconfig stuff because it is fully part of the kernel tree now. One just has to open the Real-time sub-system menu from the Kconfig toplevel to access the complete Xenomai setup, no more error-prone multiple configuration sources. I've also killed the Expert mode, all options are visible at once, so that Xeno conforms better to the Linux configuration rules. Help strings should be revisited in order to explain which defaults are sane though. Pitfalls/Caveats: - Compilation of modules is now out of Xenomai's build system scope, it's a pure Linux thing anew, so no support is provided for doing this anymore. For instance, xeno-config has twice less options than before, because all kernel compilation related stuff has disappeared. Kernel modules should be compiled the Linux way (i.e. cd your_module make -C your-kernel-tree M=$PWD). - Don't search for klatency; it's not available yet. The plan is to integrate the kernel portion as a built-in test module, and extend the user-space latency tool so that it can also be used to get the sampling results from the in-kernel module too. - The cruncher has been removed, because the test case was not sensible anymore. - Make install currently installs half of the available headers, and basically none that would be useful to build kernel modules. It is still possible to find those from the kernel tree, but this also requires to leave the full Xenomai sources accessible. This likely has to be fixed, but we need a round of discussion about what should be available from the installdir first. Btw, I've moved the default installation dir to /usr/xenomai, so that we couldn't spuriously mix pre-2.1 and 2.1 setups. - Make dist will not work properly. I've updated quickly the README.INSTALL file so that the new build procedure is explained. This document will need to be fleshen out though, since it's rather terse for now. Again, all this is very new, so review and comments
Re: [Xenomai-core] Dev branch 2.1
Ciao Philippe! prepare-kernel.sh works well - I'd suggest to ask the user for the 3 needed parameters, instead of supplying them as parameters. e.g. # scripts/prepare-kernel.sh Linux directory: [default: /usr/src/linux] : Adeos-patch: [default: none] : Architecture: [default: i386] ...or something like that. ./configure also went well, but then: # make Making all in src make[1]: Entering directory `/usr/src/xenomai-2.1/src' Making all in include make[2]: Entering directory `/usr/src/xenomai-2.1/src/include' make all-recursive make[3]: Entering directory `/usr/src/xenomai-2.1/src/include' Making all in asm-uvm make[4]: Entering directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[4]: stat:system.h: Too many levels of symbolic links make[4]: *** No rule to make target `system.h', needed by `all-am'. Stop. make[4]: Leaving directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xenomai-2.1/src' make: *** [all-recursive] Error 1 /usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h Best regards, Hannes.
