[Xenomai-core] COMEDI over RTDM (was: rtdm_event_timedwait hang-up)

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

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

Hi Alexis,

as this discussion starts to become architectural and low-level, I think
we should move it to xenomai-core and give people who are interested a
chance to jump onto it again there.

Alexis Berlemont wrote:
> Hi,
> 
>>>>> I heard rumours of some COMEDI (www.comedi.org) port over RTDM recently,
>>>>> don't know the current status.
>>>> Indeed. The rumour is called Alex.
>>> Yes, I know. I just don't wanted to drag someone to public, saying: "Hey
>>> man, already doing your job?" ;)
>> It's part of the anti-shyness treatment I'm administering to Alex...
>>
>>> But, as we all know him now, what is the current status then?
> 
> My comedi port over RTDM is not completely over (and far from perfect). The 
> mmap functionnalities have not been rewritten yet. However, I have been 
> working on
> -> the port of the comedi infrastructure layer (comedi/comedi_fops.c 
> comedi/drivers.c comedi/range.c comedidev.h etc.) 
> -> the rewriting of the driver comedi_test.c (which becomes comedi_test1.c)
> -> other test stuff has been written in comedi_test2.c (replications functions 
> to test comedi_write operations)
> -> the ports of comedi_config and comedilib (partially done for comedilib), 
> etc.
> 
> This stuff is working (minor bugs appart) and I could give you a version in 
> the next few days (I have to check "make dist" ;) and minor things).
> 
> But there are plenty of things I am not happy with :
> -> the original comedilib version is not really well suited for rtdm. In this 
> library for many reasons; for example, you can find calls to malloc/free 

Oops, not so nice.

> functions. If I stick to the original implementation, I have to either to ask 
> for adding alloc stuff in user mode in rtdm skin or use another skin to 
> manage allocations. None of these solutions seems interesting for me for many 
> reasons. A lot of people  must be thinking I am overkill, it is true that the 
> comedilib allocations should be done at init time (comedi_open, comedi_close) 
> then no need to fulfull real-time constraints but I think comedi should be 
> fully rtdm compliant; this would avoid tricky corner cases for 
> developpers/users. The best and simplest solution for me would be some slight 
> modifications in the comedilib API but I doubt everyone is OK with that.

Could you give some concrete use cases of the comedilib where dynamic
allocation is involved? I don't know that library actually. What does it
manage beyond calling the driver core?

> 
> -> I think the comedi structures organization (comedi_device, subdevice, 
> async, etc.) should be reviewed considering the rtdm architecture. Of course, 
> these modifications should not induce big changes in the comedi drivers 
> source.

Please also give concrete examples here. RTDM devices should be
manageable by the user via file descriptors, just like normal devices.
What is different, what extra information is needed?

> 
> -> etc.
> 
> In fact, I wanted to propose two versions :
> -> a first implementation as close as possible from the original 
> implementation and API.
> -> a second one a bit more adapted for rtdm.

What would be different with RTDM compared to the existing RTLinux and
RTAI support of comedi? Don't they use comedilib at all? Isn't there
some LXRT adoption in RTAI? Is it providing a different API?

> 
> Thus, we could have compared the two versions and see if everyone agrees with 
> the idea of adapting comedi infrastructure. It would have been a good 
> opportunity to work closely with comedi developers community.

Yes, that would be best. But I guess it will not be too easy, as there
seems to exist a limited interest in RT on their side. Maybe it just
takes some (more) users explaining the requirements and the need. ;)

> 
> Unfortunately, my second version is not finished yet. I still have some work 
> on it (non negligible). (I know I know I am slower than a turtle which learns 
> programming with an amstrad cpc 6128 and damaged floppy disks ). 
> 
> If someone is interested in getting a version right now, I will try to send to 
> him a tarball as soon as possible. Compared to original comedi deliveries, I 
> have not created two autotools tarballs (comedi and comedilib) but only one.

Release early, release often ;). I would offer to have a look, maybe it
will clarify where the RTDM-specific problems are.

Jan


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