Hi Wolfgang,

First of all, thx for the CAN stack. Great job.

On Thu, 2006-08-03 at 09:58 +0200, Wolfgang Grandegger wrote:
> Jan Kiszka wrote:


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

I can't speak for Jan wrt providing a RTDM add-on framework, but since
Xenomai is currently the reference platform for RTDM (at least, the
real-time infrastructure over which most of this work is experimented,
debugged and stabilized), I would rather seek integration of RTDM-based
drivers into the Xenomai tree, instead of a complete separation.

The reason being that it makes sense (to a Xenomai maintainer, that is)
to reduce the odds of discrepancies between the core real-time
framework, the driver infrastructure and the client drivers, at least
while the first two are undergoing a rapid evolution. The same "in-tree
vs out-of-tree drivers" maintenance dilema which is known from the
kernel folks will also apply to us, if RTDM, and/or RTDM over Xenomai
are as successful as we wish, i.e. creating opportunities to provide
lots of RT drivers sharing a common infrastructure.

Said differently, the day a significant number of people will start
relying on a rich collection of RTDM-based drivers over Xenomai, we
_will_ have maintenance issues to deal with, anyway, starting with
answering a lot of questions on xenomai-whatever*. In such a case, I'd
rather reduce the odds of integration issues between Xenomai-RTDM and/or
RTDM/drivers. This said, I'm not saying that Xenomai should be the only
RTDM-based driver repository in the long run; but I'm arguing that
Xenomai could be used as a centripetal force to help developing and
stabilizing the RT driver ecosystem around RTDM.


Xenomai-core mailing list

Reply via email to