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

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.

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.



Reply via email to