[Xenomai-help] RTDM context_size question

[Xenomai-help] RTDM context_size question

[Steven Kauffmann]

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

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?

Thanks in advance

Steven

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

Re: [Xenomai-help] RTDM context_size question

[Jan Kiszka]

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

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


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

Re: [Xenomai-help] RTDM context_size question

[trem]

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 ?

If yes, I'll do it ASAP.

regards,
Philippe

Re: [Xenomai-help] RTDM context_size question

[Jan Kiszka]

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.

> 
> If yes, I'll do it ASAP.
> 
> regards,
> Philippe
> 

Thanks,
Jan

Re: [Xenomai-help] RTDM context_size question

[trem]

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 == ?

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

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


>> >> If yes, I'll do it ASAP.
>> >>
>> >> regards,
>> >> Philippe
>> >>
>> >>
> >
> > Thanks,
> > Jan
> >
> >

Re: [Xenomai-core] RTDM context_size question

[Jan Kiszka]

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

Re: [Xenomai-core] RTDM context_size question

[trem]

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

Re: [Xenomai-core] RTDM context_size question

[Jan Kiszka]

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

Hi Philippe,

sorry for the delay - I was and still am short on time.

trem wrote:
> 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
> 

Let's write the full example first, look at the result, and then decide
about the best split-up.

Jan


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

Re: [Xenomai-core] RTDM context_size question

[trem]

Jan Kiszka wrote:
> Hi Philippe,
> 
> sorry for the delay - I was and still am short on time.
> 
> trem wrote:
>> 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
>>
> 
> Let's write the full example first, look at the result, and then decide
> about the best split-up.
> 
> Jan
> 

Hi

Ok, I write it and I send it ASAP.

regard,
Philippe (trem)