Re: [Xenomai-core] Comedi drivers in Xenomai porting/integration status ?

[Peter Soetens <peter.soetens@domain.hid>]

On Tuesday 17 February 2009 00:00:00 Alexis Berlemont wrote:
> Hi,
>
> > 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
> port.
>
> 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 
feedback. 
* There aren't any (?) device drivers ported to the Xenomai/Comedi project 
(public trunk)

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
-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>