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.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
