Re: [Xenomai-core] RTDM context_size question

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

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

trem wrote:
> Jan Kiszka wrote:
>> trem wrote:
>>   
>>> Jan Kiszka wrote:
>>>     
>>>> Steven Kauffmann wrote:
>>>>       
>>>>> Hi
>>>>>
>>>>> When looking at the rtdm examples tut01-skeleton en tut02-skeleton, I have a
>>>>> question about the context_size in the rtdm_device struct.
>>>>>
>>>>> In tut01-skeleton-drv.c, the context_size = sizeof(buffer_t), in the other
>>>>> example context_size = 0. Both drivers uses the
>>>>> rtdm_safe_copy_to_user/rtdm_safe_copy_from_user functions to write/read data
>>>>> from buffer_t(kernel space) to user_space. So I don't understand why the
>>>>> context_size in tut02 is different than in tut01. Or is the context_size
>>>>> only important if we open the driver several times from one or more
>>>>> user_space programs?
>>>>>         
>>>> The context size is important in case you want to attach some data to
>>>> each opened instance of a device. Hmm, but this is something neither
>>>> tut01 nor tut02 deals with optimally. tut02 cannot use a context-based
>>>> buffer, because it uses two device instances (opened by two instances of
>>>> the user space program) to transfer the data. But tut01 could use some
>>>> global buffer as well without loosing a feature.
>>>>
>>>> Philippe (trem), could you rework tut01 and make it use a global buffer
>>>> instead? Then some tut03 would be nice to explain what per context, per
>>>> device, and global data means. I've seen confusion about this fairly
>>>> often, so a dedicated tutorial would be great.
>>>>
>>>> Thanks,
>>>> Jan
>>>>
>>>>       
>>> Hi
>>>
>>> I've used per device buffer in tut01 and global buffer in tut02 to show
>>> the difference between them. But it seems that it's not very clear. And
>>> as the tut01 is just here as first rtdm example, it should be as simple
>>> as possible.
>>>
>>> So yes, using global buffer in tut01 and tut02 could be done, and I will
>>> add a tut03 to show the context.
>>>
>>> tutorial index :
>>> - tut01 : first rtdm program
>>> you can read and write in this device (tut01-skeleton-drv01). All data
>>> are global, so I two program read it, they will read the same thing.
>>>
>>> - tut02 : show synchronization
>>> you can only read in the device (tut02-skeleton-drv01) if a write has
>>> been done before (by this program or another program). data and
>>> semaphore are global.
>>>
>>> - tut03 : show device context
>>> we can use tut01, and just put data to context. So a program can't read
>>> data written by another program. For example, P1 and P2 two programs.
>>>
>>> with tut01, the sequence is :
>>> P1 : write "I'm P1" to tut01-skeleton-drv01
>>> P2 : write "I'm P2" to tut01-skeleton-drv01
>>> P1 : read  "I'm P2" from tut01-skeleton-drv01
>>> P2 : read  "I'm P2" from tut01-skeleton-drv01
>>>
>>> with tut03, the sequence is :
>>> P1 : write "I'm P1" to tut03-skeleton-drv01
>>> P2 : write "I'm P2" to tut03-skeleton-drv01
>>> P1 : read  "I'm P1" from tut03-skeleton-drv01
>>> P2 : read  "I'm P2" from tut03-skeleton-drv01
>>>
>>>
>>> I'm on the right way ?
>>>     
>> Basically, yes. But I would even put all three associations into the
>> same example, may be letting the tut-device user select the data
>> destination via an IOCTL: local, device, global. That would should
>> clearly the association - and would also introduce a first, simple IOCTL
>> mechanism.
>>
>>   
> First, sorry, I don't understand the 3 choice : local, device, global.
> global == 1 buffer for a driver
> local   == 1 buffer each open
> device == ?

"MyDevice01", "MyDevice02", ...

Means your driver registered multiple devices of the same kind. But, as
I just realised, this is something not yet covered by the tutorials as well.

> 
> Are you sure you want to do only one tut with all this choice ?
> People seems to have some problem to understand a simple example,
> and you want to regroup them ?
> 
> I propose :
> tut01 => really simple example, global buffer
> tut02 => synchronization
> tut03 => context
> tut04 => ioctl
> 
> You propose :
> tut01 => really simple example (like helloworld)
> tut02 => context + synchronizatio + ioctl

Nope, no ioctl for tut02 yet.

> 
> Both of them have pros and cons, which one you prefer ?

The idea was to give that data a bit more sense so that the examples are
less abstract.

Suggestion: Splitting up into several steps is always possible, let's
write down a version that covers all aspects and THEN decide which of
them is worth a dedicated tutorial (maybe you can leave the user space
part unmodified then). This approach would have the advantage to make it
clearer where the tutorials will take us and assure that there is at
best some thread from the beginning to the end.

Thanks,
Jan


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