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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]