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. >> >> >> > >
