Jan Kiszka wrote:
> 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
> 

Hi

Oh, I understand your point of view, and I found it fine. We do an
example quite complete (and with some sense), and we split it into step.

The first complete example could contain :
- global buffer (one for all device)
- device buffer (one for each device)
- local buffer (one for each open)
- synchronization: semaphore used to block read when no data are ready
- ioctl: used to to select the active buffer (ie global, device, local)

Now, how to split it ? I propose :

tut01: global buffer + read/write
tut02: {global, device, local} buffer + ioctl + read/write
tut03: {global, device, local} buffer + ioctl + read/write + synchronization


regards,
Philippe



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

Reply via email to