All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] Dev branch 2.1
@ 2005-11-02 11:18 Philippe Gerum
  2005-11-02 21:57 ` Hannes Mayer
  0 siblings, 1 reply; 10+ messages in thread
From: Philippe Gerum @ 2005-11-02 11:18 UTC (permalink / raw)
  To: xenomai


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 are welcome. The window for 
tree reorganization is still open.

http://svn.gna.org/viewcvs/xenomai/branches/v2.1/

-- 

Philippe.


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-11-03 21:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-02 11:18 [Xenomai-core] Dev branch 2.1 Philippe Gerum
2005-11-02 21:57 ` Hannes Mayer
2005-11-03  8:01   ` Philippe Gerum
2005-11-03  8:44     ` h.mayer
2005-11-03  8:51       ` Romain Lenglet
2005-11-03 10:11     ` Wolfgang Grandegger
2005-11-03 19:27       ` Hannes Mayer
     [not found]         ` <436A654A.5050805@domain.hid>
2005-11-03 19:55           ` Hannes Mayer
2005-11-03 21:20             ` Philippe Gerum
2005-11-03 20:25         ` Wolfgang Grandegger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.