Ignacio García Pérez wrote:
I had a first contact with the new build system. I really really don't
like the fact it touches my kernel source tree. Besides adeos, I like to
keep the kernel source independent of xenomai, because that tree is
shared for other projects.

At that point, I would really consider leaving the burden of keeping various users of a single code base in sync to a SCM, not to the filesystem.

Also, why does it default to monolithic build of the xeno modules when
in 2.0 you always got them as modules?.

Because it's a reasonable default:

o Most setups don't need to unload the real-time support, but rather load it once for all at startup. o Given #1, in the embedded space, modules are often considered as pure annoyance. Among other things, you need to activate the module support in the kernel just to load the RT system once, and this does not come for free, especially in terms of memory footprints. o Modules are allocated in vmalloc space. Given that the vanilla kernel already has rather poor code locality (spatially speaking at least), things are not going to improve for time-critical code in modules which increase TLB misses.

For the rare cases where the arguments above are outweight by a strong requirement to have modules, you can still switch them on in your kernel configuration; this is the kind of flexibility you did not have with the previous build system.



Xenomai-core mailing list

Reply via email to