On Tuesday 17 February 2009 00:00:00 Alexis Berlemont wrote:
> > Hello all! I would like to know what is the current status of the Comedi
> > port to Xenomai.
> > Should all the specific Comedi drivers (ni_pcimio, ni_mite) be available
> > for testing (by me or someone with a supported DAQ card) and (if ok) for
> > futher integration ?
> I am still working on that port. It is a long work and I am wondering at
> each line whether I should rewrite any part of code which does not comply
> with common coding constraints. Unfortunately, I currently do not have a
> lot of spare time. Anyway, most of the ni subdevices drivers have been
> ported (mite, tio, mio, 8255). I am trying to finalize the global driver
> By the way, in the middle of january, I noticed that the legacy Comedi
> branch found its way into the mainline (through the staging tree). I do not
> know what will be the future of such a package in mainstream. I assume the
> main goal is the definition of a global framework for acquisition boards
> like V4L2 is for video cards.
I'm not sure I understand where this is going. We did a review of the
Xenomai/Comedi code integration a few weeks ago.
These are the facts we observed:
* The Xenomai/Comedi port breaks the complete Comedi API, user space *and*
kernel space. (We thought/assumed that only the user space interface would go
over RTDM and that once that was done, the kernel modules could be almost
copy/pasted into the new framework.)
* The Xenomai/Comedi port is not supported by 'upstream' (what you call
'legacy'). It's not discussed on their ML, they don't send in patches or
* There aren't any (?) device drivers ported to the Xenomai/Comedi project
This is what we concluded:
* Xenomai/Comedi has no future as long as it ignores (or is ignored by)
upstream. Even after a port of a device driver, pulling fixes from upstream
will be hard due to the changed kernel API.
* As GKH puts it: all device drivers belong in the Linux kernel. Upstream is
doing this right now, which makes acceptance of Xenomai/Comedi unlikely, which
makes its life expectations uncertain.
* We're now actually considering Preempt/RT as the kernel to use in
combination with the original Comedi. We might be stupid, but then again, it
might just work.
* We believe the name Xenomai/Comedi is strongly misleading. It suggests a
painless transition path, but it's a completely different software project,
different interfaces, different maintainer(s ?).
Sorry for flaming, and please correct me where I'm wrong.
Peter Soetens -- FMTC -- <http://www.fmtc.be>
Xenomai-core mailing list