Jan Kiszka wrote:
instead of replying directly to Wolfgang's announcement of their great
CAN stack I take the chance to start a generic thread on the future of
RTDM drivers *within* Xenomai.
If you look at the real-time Linux scene now and in the past, you may
find it fairly scattered. Specifically precious Open Source drivers are
hard to find, not always up-to-date, or not ported to your favourite
kernel/RT-patch. Just check how many CAN driver projects for how many RT
APIs are out there. There are even a few hardware vendors providing
driver packages for real-time Linux, others offer at least some kind of
"reference code", but many nothing at all. Sad but true for _many_ years.
RTDM came into play to provide a common ground for real-time driver
development under Linux. It is already utilised by quite a few
stand-alone driver projects and even vendor drivers. But as resources
are limited, maintenance is tricky, and testers are rare, we should
consider concentrating driver development efforts more intensively. I'm
convinced such concentration should primarily happen within the Xenomai
Xenomai has the unique potential to provide a real-time framework for
both the co-scheduling approach and for the native RT-Linux environment
that Preempt-RT will probably push into mainline one day. And Xenomai is
also a sound foundation for the tricky 2.4/2.6 support scenario.
Here are the concrete advantages I see in maintaining drivers *inside*
o Better visibility (did you know that there is a working FireWire
stack for Xenomai?)
o Better testing, also across architectures, due to more users (this
applies to the drivers, but also to RTDM and Xenomai in all)
o Closer to the latest RTDM development
o Wrapping environments for changing kernel interfaces (2.4/2.6 etc.)
o In-kernel build
o Simpler build system (look at RTnet...)
o Single, integrated package, thus less breakages due to version
Of course, there are also certain critical topics that need to be
o Clear acceptance rules
- Maintenance commitment: "dump-and-run" will not scale. Unless
there is already a community behind it, complex drivers need
people to look after them. Dead/unused drivers should get moved in
some corner after a while.
- Coding style: Should simply be kernel style (though I personally
- Documentation: New RTDM profiles as well as the drivers themselves
must contain "some words" (surely a more softish requirement).
- Test cases, test conformance: Drivers should provide some simple
tests or, if once available, conform to existing tests for their
o Repository organisation
- Where to keep utilities (Wolfgang raised this as well)? Should a
"rtcanconfig" come with Xenomai, as a separate package of
rt-utils, or as package of its own?
- Where to put test cases? Distribute them separately?
- Where to collect usage examples? This is actually a generic
question, also for the skins (I think the current situation is
a bit unsatisfactory).
o Support organisation
Simple drivers can certainly be managed via xenomai-help, existing
communities will continue to use their own forums, but what about
new subsystems? I could imagine introducing some
[EMAIL PROTECTED] lists for them, Philippe suggested
simply xenomai-drivers which is likely already sufficient.
Now I would suggest to look at RTCAN (or what it will be called in the
end) and to discuss on this first concrete example how we can proceed
towards the sketched goal.
Looking forward to your feedback!
As you have said, maintaining a RTDM driver within the Xenomai
repository clearly has some advantages but it also puts more burden onto
the Xenomai maintainers and some developers might even prefer to keep
thing separated. Therefore I suggest a simple RTDM add-on framework to
support external RTDM drivers as well. They could be announced and
listed on the Xenomai home page and then it would alsl be visible that
there is a FireWire stack for Xenomai.
What I had first was a add-rtdm-driver.sh, a modified version of
Philippe's prepare-kernel.sh script, to add the RTDM driver to the
kernel tree. Similarly, as script could be used to add "loosely" the
driver to Xenomai.
What do you think?
Xenomai-core mailing list