Hi,
among the software we use and which is not packaged yet is RTAI, a
realtime extension to the kernel plus a set of services (modules plus
APIs) for realtime programming [1].
Having built this package locally without any problems (with the help
of make-kpkg) i thought of an "ITP: kernel-image-rtai ..." plus a
modules and a documentation/examples package. I'd happily maintain
these packages for all platforms RTAI supports (currently x86, ppc,
arm and mips). Then i searched the docs for a kernel-image policy. My
major question was, how to test the kernel on platforms i don't have
(the buildd building host obviously will not reboot after having built
this package ;^) and what other rules to follow for a core component
as the kernel.
I did not find anything in that direction, only an older thread on
that topic [2] and the conclusion was, having already so many variants
of the kernel one should not build a new binary image but instead
build a kernel-patch package and let the (assumed few) users that need
it apply it and build their own kernel.
As i think this is fine for many of those bug-fix patches, i think
there could be a broader interest in a hard-realtime capable, free
distribution:
- Linux is more and more discussed and accepted as an alternative to
commercial RTOS in the automation business (the area where we are
working, see [3] for a bunch of links)
- a lot of engineers are open minded to try out a realtime extension
(as RTAI), but it's not included in the well-known commercial
distros
- OTOH they might not fiddle around with patches on their own, maybe
breaking their desktop system
- there are some smaller, dedicated distros which are not so well-
known and cost more (but usually provide, of course, custom
addons)
So my questions/suggestions are:
1 When is a kernel patch important/serious/useful/... enough to
justify a new binary image?
2 Would the suggested package fall under the point above?
3 If not (yet), maybe this could become a new sub-project like
Desktop or debian-jr? If not alone, maybe together with emdebian
[4], which would be a useful combination in several respects?
Thanks,
Edelhard
[1] http://www.aero.polimi.it/~rtai/
[2] http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01593.html
[3] http://puffinplc.control.com/PuffinPLC_links
[4] http://www.emdebian.org/
--
~
~
:wq
Attachment:
pgp29rHeG14nC.pgp
Description: PGP signature