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

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

[Cristian Axenie]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

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 ?

Thanks !

Best,

Cristian

[-- Attachment #2: Type: text/html, Size: 326 bytes --]

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

[Alexis Berlemont]

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. 

Starting from here, I have been thinking on some alternatives so as to benefit 
from the kernel code. But I am a bit perplexed as the code does not seem to 
evolve a lot (the 2.6.29-rc5 patch still contains some rtlinux/rtai/fusion 
related code). I was unable to notice any significant work on the framework 
to reach main kernel standards.

Since the beginning of January, there was only one mail thread which dealt 
with Comedi on the lkml (which is, by the way, interesting): 
http://lkml.org/lkml/2009/2/9/335

I would be very interested in opening a discussion on that issue so as to 
define Comedi's next steps in Xenomai.

Alexis.

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

[Cristian Axenie]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

Hello

On Tue, Feb 17, 2009 at 1:00 AM, Alexis Berlemont <berlemont.hauw@domain.hid>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.


So shall we have a first version to test into the trunk?

>
>
> 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 of this due to the fact that are still more users in the
industry area that are
using Comedi for their DAQ cards.


>
>
> Starting from here, I have been thinking on some alternatives so as to
> benefit
> from the kernel code. But I am a bit perplexed as the code does not seem to
> evolve a lot (the 2.6.29-rc5 patch still contains some rtlinux/rtai/fusion
> related code). I was unable to notice any significant work on the framework
> to reach main kernel standards.
>
> Since the beginning of January, there was only one mail thread which dealt
> with Comedi on the lkml (which is, by the way, interesting):
> http://lkml.org/lkml/2009/2/9/335


I was aware of that article but I think that before starting optimizing the
code for certain needs it is necessary to
have just a ported version that fulfilled the needs for most users using
RTAI. Indeed some modifications are needed (memory mapping for low level DIO
!!) but they are local, so
patching will be available for the interested part of the Xenomai community
in upgrading the drivers. Due to the importance of integrating these drivers
into Xenomai you should consider
that the improvement of the code will be progressive as the users experience
new challenges with their hardware in RT apps.

>
> I would be very interested in opening a discussion on that issue so as to
> define Comedi's next steps in Xenomai.


good idea !



>
> Alexis.


Best,

Cristian

>
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>

[-- Attachment #2: Type: text/html, Size: 4248 bytes --]

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

[Peter Soetens]

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>

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

[Jan Kiszka]

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. 
> 
> Starting from here, I have been thinking on some alternatives so as to benefit 
> from the kernel code. But I am a bit perplexed as the code does not seem to 
> evolve a lot (the 2.6.29-rc5 patch still contains some rtlinux/rtai/fusion 
> related code). I was unable to notice any significant work on the framework 
> to reach main kernel standards.
> 
> Since the beginning of January, there was only one mail thread which dealt 
> with Comedi on the lkml (which is, by the way, interesting): 
> http://lkml.org/lkml/2009/2/9/335

The staging tree does not start an automatic merging process. Unless the
original maintainers or some new pusher (don't count on GKH for this)
step in and work with the kernel people to address remaining issues
beyond coding style, staging may also be a dead end (specifically if the
project is adding a new user space interface that always needs extra
care). For larger projects like comedi, I would say staging is more of a
test if someone is serious about mainlining it.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

Peter Soetens wrote:
> 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.)

Maybe you have a list of the major differences. Then please share it so
that the motivation can be discussed here and maybe clarified (it's a
blurred topic for me as well).

> * 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.

IMHO, that heavily depends on the use cases both projects are able to
cover. If there are major RT design issues upstream that this variant
solves, then people may be willing to live with the differences
(including a smaller driver set downstream). It wouldn't be the first time.

> * 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.

I don't think anyone expect to see the RT drivers here and around in
mainline Linux in the foreseeable future. That's not the primary goal.
At the same time, it's still unclear how serious mainline is about RT
redesigns of existing drivers or frameworks. And I recall from earlier
threads on the comedi list that at least the current comedi maintainers
consider RT use at best as a niche and not an important scenario.

> * 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 ?).

I agree. If reasons for significant differences in the user API remain,
then a different name would be appropriate, too. Looks like this is not
Socket-CAN vs. RT-Socket-CAN here?

> 
> Sorry for flaming, and please correct me where I'm wrong.

Sometime "flaming" can even be helpful... :)

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Peter Soetens]

On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
> Peter Soetens wrote:
> > 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.)
>
> Maybe you have a list of the major differences. Then please share it so
> that the motivation can be discussed here and maybe clarified (it's a
> blurred topic for me as well).

Damn. I should have posted back then :-) Our main lead was the Doxygen pages, 
from which we went on to see how things were done in code. Unfortunately (?), 
I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I 
can't really compare to the bone. But what was clear immediately was that both 
user API and kernel API were different. 

User ('Library') API was cleaned up and streamlined, we could live with that 
for new applications. I'm sure there are still issues, but they'll only come 
up once people start using this branch. I like the separation between a low 
level 'instruction' api and a high level 'function' api. Something upstream 
comedi mixes to much.

For kernel ('Driver') API, a new data transfer mechanism is in place, which 
requires the 'porting' of all drivers. I genuinely can't estimate how 
drastically this changes existing drivers, but the API is quite huge and works 
with the 'inversion of control' paradigm: Each driver must implement a series 
of hooks, and the Comedi/RTDM framework will call these when necessary.

Another fact I shouldn't have omitted:

* The Xenomai/Comedi layer is very well documented and allows anyone to learn 
from it, even the upstream maintainers.
* Seen from my little device driver knowledge, the technical implementation 
looks ok for synchronous/asynchronous reading and writing. Memory mapped IO is 
not available, it seems, and the classical comedi_config, inp,outp,... family 
isn't complete yet either.

>
> > * 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.
>
> IMHO, that heavily depends on the use cases both projects are able to
> cover. If there are major RT design issues upstream that this variant
> solves, then people may be willing to live with the differences
> (including a smaller driver set downstream). It wouldn't be the first time.

I see the short term profits as well. I'm fearing a maintenance nightmare in 
the long term.

>
> > * 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.
>
> I don't think anyone expect to see the RT drivers here and around in
> mainline Linux in the foreseeable future. That's not the primary goal.
> At the same time, it's still unclear how serious mainline is about RT
> redesigns of existing drivers or frameworks. And I recall from earlier
> threads on the comedi list that at least the current comedi maintainers
> consider RT use at best as a niche and not an important scenario.

That's what I recall as well. But I was wondering how the RT issue was 
overtaken by reality: running plain comedi in a preemptible kernel.

>
> > * 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 ?).
>
> I agree. If reasons for significant differences in the user API remain,
> then a different name would be appropriate, too. Looks like this is not
> Socket-CAN vs. RT-Socket-CAN here?

Most functions and structs have been renamed and have modified arguments, 
although there could be a 1:1 mapping (1 old function -> 1 new function).

I believe Alexis can defend his design better than anyone else, and it's not 
the design I wanted to tackle. It's how he plans to maintain it.

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>

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

[Jan Kiszka]

Peter Soetens wrote:
> On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
>> Peter Soetens wrote:
>>> 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.)
>> Maybe you have a list of the major differences. Then please share it so
>> that the motivation can be discussed here and maybe clarified (it's a
>> blurred topic for me as well).
> 
> Damn. I should have posted back then :-) Our main lead was the Doxygen pages, 
> from which we went on to see how things were done in code. Unfortunately (?), 
> I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I 
> can't really compare to the bone. But what was clear immediately was that both 
> user API and kernel API were different. 
> 
> User ('Library') API was cleaned up and streamlined, we could live with that 
> for new applications. I'm sure there are still issues, but they'll only come 
> up once people start using this branch. I like the separation between a low 
> level 'instruction' api and a high level 'function' api. Something upstream 
> comedi mixes to much.
> 
> For kernel ('Driver') API, a new data transfer mechanism is in place, which 
> requires the 'porting' of all drivers. I genuinely can't estimate how 
> drastically this changes existing drivers, but the API is quite huge and works 
> with the 'inversion of control' paradigm: Each driver must implement a series 
> of hooks, and the Comedi/RTDM framework will call these when necessary.
> 
> Another fact I shouldn't have omitted:
> 
> * The Xenomai/Comedi layer is very well documented and allows anyone to learn 
> from it, even the upstream maintainers.
> * Seen from my little device driver knowledge, the technical implementation 
> looks ok for synchronous/asynchronous reading and writing. Memory mapped IO is 
> not available, it seems, and the classical comedi_config, inp,outp,... family 
> isn't complete yet either.

The latter point surprises me given that Alexis worked a lot with/on the
related RTDM services for memory mapping.

> 
>>> * 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.
>> IMHO, that heavily depends on the use cases both projects are able to
>> cover. If there are major RT design issues upstream that this variant
>> solves, then people may be willing to live with the differences
>> (including a smaller driver set downstream). It wouldn't be the first time.
> 
> I see the short term profits as well. I'm fearing a maintenance nightmare in 
> the long term.

No question, that remains an important aspect!

> 
>>> * 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.
>> I don't think anyone expect to see the RT drivers here and around in
>> mainline Linux in the foreseeable future. That's not the primary goal.
>> At the same time, it's still unclear how serious mainline is about RT
>> redesigns of existing drivers or frameworks. And I recall from earlier
>> threads on the comedi list that at least the current comedi maintainers
>> consider RT use at best as a niche and not an important scenario.
> 
> That's what I recall as well. But I was wondering how the RT issue was 
> overtaken by reality: running plain comedi in a preemptible kernel.

As we know (or learned painfully): Just switching the kernel doesn't
always make its users RT-safe. :)

> 
>>> * 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 ?).
>> I agree. If reasons for significant differences in the user API remain,
>> then a different name would be appropriate, too. Looks like this is not
>> Socket-CAN vs. RT-Socket-CAN here?
> 
> Most functions and structs have been renamed and have modified arguments, 
> although there could be a 1:1 mapping (1 old function -> 1 new function).
> 
> I believe Alexis can defend his design better than anyone else, and it's not 
> the design I wanted to tackle. It's how he plans to maintain it.
> 
> Peter
> 

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Alexis Berlemont]

Hi,

Peter Soetens <peter.soetens@domain.hid> writes:

> On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
>> Peter Soetens wrote:
>> > 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.)
>>
>> Maybe you have a list of the major differences. Then please share it so
>> that the motivation can be discussed here and maybe clarified (it's a
>> blurred topic for me as well).
>
> Damn. I should have posted back then :-) Our main lead was the Doxygen pages, 
> from which we went on to see how things were done in code. Unfortunately (?), 
> I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I 
> can't really compare to the bone. But what was clear immediately was that both 
> user API and kernel API were different. 
>
> User ('Library') API was cleaned up and streamlined, we could live with that 
> for new applications. I'm sure there are still issues, but they'll only come 
> up once people start using this branch. I like the separation between a low 
> level 'instruction' api and a high level 'function' api. Something upstream 
> comedi mixes to much.
>
> For kernel ('Driver') API, a new data transfer mechanism is in place, which 
> requires the 'porting' of all drivers. I genuinely can't estimate how 
> drastically this changes existing drivers, but the API is quite huge and works 
> with the 'inversion of control' paradigm: Each driver must implement a series 
> of hooks, and the Comedi/RTDM framework will call these when necessary.

Just to sum-up why the whole Comedi API suffers so many changes from
the upstream Comedi API (sorry for 'legacy'):

* At the very beginning (If I remember well), I just wanted to port
  the current Comedi layer so as to comply with RTDM API. My first
  resolution was to leave the drivers set unchanged so as to
  seamlessly use them in the ported framework. However, I was facing
  many issues (RT/NRT contexts, mix with kernel API, etc.) I could not
  handle without altering drivers code. Eventually, I was unable to
  provide a coherent RTDM Comedi module considering the code
  organization.

* That was the point which makes try to overhaul the original
  branch. I sent an email on the Comedi mailing list. I received no
  answer; by the way, the activity seemed quite low. I wanted to
  develop a Comedi infrastructure usable on both configurations
  (common Linux API and RTDM). Fulfilling such a constraint led me to
  redefine the kernel driver API. Before integrating the code into
  Xenomai's trunk, I decided to drop the common Linux interface while
  keeping in mind that the RTDM-native module would allow the new
  Comedi core to run on common kernels (maybe that was a
  mistake). That is why, the driver API still have the context notion;
  I should remove it.

Then I did my best to design a coherent layer. There are still many
flaws to be improved. Notably at the driver level, the API is too
closed. I (and/or anyone interested) should find a way to provide more
freedom to drivers developers.

Concerning the library API, I just thought there were too many
functions in comedilib, and some were redundant with each other. I
tried to propose an alternative like the native skin API was an
alternative to the RTAI API. Maybe I was wrong.

All that work relied on my assumption that upstream Comedi was not
very active anymore. Then, it was an opportunity for me to have fun
trying to deliver an RTDM port based on a new architecture.

That was the reason why, I was really suprised to find Comedi
integrated into the mainline kernel. What strikes me more is that
Comedi seems to be left as is. Do you think, it will be cleaned up or
reworked ?

> Another fact I shouldn't have omitted:
>
> * The Xenomai/Comedi layer is very well documented and allows anyone to learn 
> from it, even the upstream maintainers.
> * Seen from my little device driver knowledge, the technical implementation 
> looks ok for synchronous/asynchronous reading and writing. Memory mapped IO is 
> not available, it seems, and the classical comedi_config, inp,outp,... family 
> isn't complete yet either.

I thought comedi_buf_prepare/commit functions were OK to implement
memory mapped IO. Could you explain me what must be added?

For comedi_config, could you tell me what is missing?

>
> I believe Alexis can defend his design better than anyone else, and it's not 
> the design I wanted to tackle. It's how he plans to maintain it.

Once Philippe told me: "one never knows.. a misunderstanding could
make it work" ;)

Seriously, I thought the Xenomai/Comedi could be an interesting
alternative for the original Comedi to keep on providing open source
drivers for data acquisition cards. I understand that the API breakage
is a critical issue which threatens its interest. I will reconsider
the development of a transition layer but last time I thought about
it, I faced so many problems that I gave up.

Many thanks for having a look at the code. I more than welcome any
critics (even flames or anything else). That is, I think, a nice way
to prevent me from making the same mistake many times.

Alexis.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]

Alexis Berlemont wrote:
> Hi,
> 
> Peter Soetens <peter.soetens@domain.hid> writes:
> 
>> On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
>>> Peter Soetens wrote:
>>>> 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.)
>>> Maybe you have a list of the major differences. Then please share it so
>>> that the motivation can be discussed here and maybe clarified (it's a
>>> blurred topic for me as well).
>> Damn. I should have posted back then :-) Our main lead was the Doxygen pages, 
>> from which we went on to see how things were done in code. Unfortunately (?), 
>> I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I 
>> can't really compare to the bone. But what was clear immediately was that both 
>> user API and kernel API were different. 
>>
>> User ('Library') API was cleaned up and streamlined, we could live with that 
>> for new applications. I'm sure there are still issues, but they'll only come 
>> up once people start using this branch. I like the separation between a low 
>> level 'instruction' api and a high level 'function' api. Something upstream 
>> comedi mixes to much.
>>
>> For kernel ('Driver') API, a new data transfer mechanism is in place, which 
>> requires the 'porting' of all drivers. I genuinely can't estimate how 
>> drastically this changes existing drivers, but the API is quite huge and works 
>> with the 'inversion of control' paradigm: Each driver must implement a series 
>> of hooks, and the Comedi/RTDM framework will call these when necessary.
> 
> Just to sum-up why the whole Comedi API suffers so many changes from
> the upstream Comedi API (sorry for 'legacy'):
> 
> * At the very beginning (If I remember well), I just wanted to port
>   the current Comedi layer so as to comply with RTDM API. My first
>   resolution was to leave the drivers set unchanged so as to
>   seamlessly use them in the ported framework. However, I was facing
>   many issues (RT/NRT contexts, mix with kernel API, etc.) I could not
>   handle without altering drivers code. Eventually, I was unable to
>   provide a coherent RTDM Comedi module considering the code
>   organization.
> 
> * That was the point which makes try to overhaul the original
>   branch. I sent an email on the Comedi mailing list. I received no
>   answer; by the way, the activity seemed quite low. I wanted to
>   develop a Comedi infrastructure usable on both configurations
>   (common Linux API and RTDM). Fulfilling such a constraint led me to
>   redefine the kernel driver API. Before integrating the code into
>   Xenomai's trunk, I decided to drop the common Linux interface while
>   keeping in mind that the RTDM-native module would allow the new
>   Comedi core to run on common kernels (maybe that was a
>   mistake). That is why, the driver API still have the context notion;
>   I should remove it.
> 
> Then I did my best to design a coherent layer. There are still many
> flaws to be improved. Notably at the driver level, the API is too
> closed. I (and/or anyone interested) should find a way to provide more
> freedom to drivers developers.
> 
> Concerning the library API, I just thought there were too many
> functions in comedilib, and some were redundant with each other. I
> tried to propose an alternative like the native skin API was an
> alternative to the RTAI API. Maybe I was wrong.
> 
> All that work relied on my assumption that upstream Comedi was not
> very active anymore. Then, it was an opportunity for me to have fun
> trying to deliver an RTDM port based on a new architecture.
> 
> That was the reason why, I was really suprised to find Comedi
> integrated into the mainline kernel. What strikes me more is that
> Comedi seems to be left as is. Do you think, it will be cleaned up or
> reworked ?

Without rework Comedi will not make into mainline (I wouldn't call the
staging corner "mainline"). And when reading this
http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
best time now to propose interface changes and contribute back
improvements made for the RTDM rework.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Alexis Berlemont]

Hi,

>> That was the reason why, I was really suprised to find Comedi
>> integrated into the mainline kernel. What strikes me more is that
>> Comedi seems to be left as is. Do you think, it will be cleaned up or
>> reworked ?
>
> Without rework Comedi will not make into mainline (I wouldn't call the
> staging corner "mainline"). And when reading this
> http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
> best time now to propose interface changes and contribute back
> improvements made for the RTDM rework.

How would you proceed ? Maybe, the first step would be to ask on the
Comedi mailing-list if someone is interested in discussing on the API
rework. Maybe, someone will answer this time. 

Alexis.

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

[Anders Blomdell]

Alexis Berlemont wrote:
> Hi,
> 
>>> That was the reason why, I was really suprised to find Comedi
>>> integrated into the mainline kernel. What strikes me more is that
>>> Comedi seems to be left as is. Do you think, it will be cleaned up or
>>> reworked ?
>> Without rework Comedi will not make into mainline (I wouldn't call the
>> staging corner "mainline"). And when reading this
>> http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
>> best time now to propose interface changes and contribute back
>> improvements made for the RTDM rework.
> 
> How would you proceed ? Maybe, the first step would be to ask on the
> Comedi mailing-list if someone is interested in discussing on the API
> rework. Maybe, someone will answer this time. 
If it is more informative than the mail from 06-04-09 and the presentation.txt
there is definitely a chance :-), I read through it then, found the goals
reasonably sound, and nothing to test, so I waited for some working code to show
up (having too much at my hands already), that time might have come now.

Features I would like to see in a Comedi/RTDM framework are:

1. Drivers should work in Linux, Xenomai (and possibly RTAI and/or RT-Linux)
2. It should be possible to write drivers that live in user-space (serial2002
driver is a big HACK).
3. Stackable drivers (e.g. put a force sensor driver on top of a analog input card).
4. A comedilib compatibilty library would be nice (but not necessary)

If all these pieces are in place, I'm more than happy to test/migrate the
drivers I use in my labs (JR3, NI M6221, DaqBoard 2000, ACPI 3106, serial)

Best regards

Anders Blomdell

-- 
Anders Blomdell                  Email: anders.blomdell@domain.hid
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

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

[Jan Kiszka]

Alexis Berlemont wrote:
> Hi,
> 
>>> That was the reason why, I was really suprised to find Comedi
>>> integrated into the mainline kernel. What strikes me more is that
>>> Comedi seems to be left as is. Do you think, it will be cleaned up or
>>> reworked ?
>> Without rework Comedi will not make into mainline (I wouldn't call the
>> staging corner "mainline"). And when reading this
>> http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
>> best time now to propose interface changes and contribute back
>> improvements made for the RTDM rework.
> 
> How would you proceed ? Maybe, the first step would be to ask on the
> Comedi mailing-list if someone is interested in discussing on the API
> rework. Maybe, someone will answer this time. 

As Anders also said: Make it as concrete as possible. List concrete
changes and explain their motivations and benefits. Ideally, even
provide RFC patches (unless the effort is so huge that waiting for first
comments is more appropriate). Also, I would consider putting LKML on CC
when the kernel ABI is affected - to underline that this is targeting
the staging work.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Peter Soetens]

On Thursday 19 February 2009 00:43:56 Alexis Berlemont wrote:
> Hi,
>
> >> That was the reason why, I was really suprised to find Comedi
> >> integrated into the mainline kernel. What strikes me more is that
> >> Comedi seems to be left as is. Do you think, it will be cleaned up or
> >> reworked ?
> >
> > Without rework Comedi will not make into mainline (I wouldn't call the
> > staging corner "mainline"). And when reading this
> > http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
> > best time now to propose interface changes and contribute back
> > improvements made for the RTDM rework.
>
> How would you proceed ? Maybe, the first step would be to ask on the
> Comedi mailing-list if someone is interested in discussing on the API
> rework. Maybe, someone will answer this time.

Much wil depend on how you approach upstream. An example: Keith Packard and 
Ingo Molnar managed to push major changes into the Linux kernel mainline. Not 
by forcing yet another architecture into Linus' throat, but by saying "Hey, I 
need these video services from the kernel, how should we fix that?" or saying: 
'Look how broken locking imlementation X is, I have a patch that cleans it up, 
and by the way, adds priority inheritance." 

What I'm saying is tht it's very risky to ask upstream to move to you. But if 
you move to upstream, success is almost guaranteed.

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>

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

[Jan Kiszka]

Peter Soetens wrote:
> On Thursday 19 February 2009 00:43:56 Alexis Berlemont wrote:
>> Hi,
>>
>>>> That was the reason why, I was really suprised to find Comedi
>>>> integrated into the mainline kernel. What strikes me more is that
>>>> Comedi seems to be left as is. Do you think, it will be cleaned up or
>>>> reworked ?
>>> Without rework Comedi will not make into mainline (I wouldn't call the
>>> staging corner "mainline"). And when reading this
>>> http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the
>>> best time now to propose interface changes and contribute back
>>> improvements made for the RTDM rework.
>> How would you proceed ? Maybe, the first step would be to ask on the
>> Comedi mailing-list if someone is interested in discussing on the API
>> rework. Maybe, someone will answer this time.
> 
> Much wil depend on how you approach upstream. An example: Keith Packard and 
> Ingo Molnar managed to push major changes into the Linux kernel mainline. Not 
> by forcing yet another architecture into Linus' throat, but by saying "Hey, I 
> need these video services from the kernel, how should we fix that?" or saying: 
> 'Look how broken locking imlementation X is, I have a patch that cleans it up, 
> and by the way, adds priority inheritance." 
> 
> What I'm saying is tht it's very risky to ask upstream to move to you. But if 
> you move to upstream, success is almost guaranteed.

Another lesson to term: Step by step.

It might be a good idea to start the discussion with (probably) less
controversial proposals, proving that way that you are willing to
contribute and able to provide good changes, and after that starting
discussions on more invasive modifications.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux