Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Fevereiro 2006 05:55, voc=EA escreveu:
>Rodrigo Rosenfeld Rosas wrote:
>> Jan Kiszka escreveu:
>>> Rodrigo Rosenfeld Rosas wrote:
>>>> Jan Kiszka escreveu:
>>>>> Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>>> still need some means to prevent the scenario you described above.
>>>>> Actually, all you need is some callback when the mapped memory block
>>>>> was
>>>>> actually released (munmap/application exit). Such a callback can be
>>>>> registered inside the rtdm_mmap handler as a vma_fileop.
>>>>
>>>> I have never worked with vma_fileop... I would need to learn it first.
>>>
>>> Here is the patch to offer you access to those ops. Revert the previous
>>> version, then apply this one.
>>
>> Actually I would have to revert the modifications I had to do for the
>> patch to apply (some rejected chunks). But I think I'll update to the
>> last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2
>> xenomai? Or it would apply for all of them?
>
>Developed and tested against 2.1. The current patch will not cleanly
>apply against 2.0.

Ok, it already applied cleanly on last svn version. I'll reboot my computer
and test it. That is something I didn't like in 2.1 series... I always have
to recompile the kernel and to reboot when a new xenomai release is availab=
le
(unless I'm missing something)... On the previous series I just compiled it
as modules and it was only necessary to recompile the kernel when a new ade=
os
(ipipe) version was available...

>>> It still needs some final documentation
>>> notes and a test on kernel 2.4. But is should already work on 2.6.
>>
>> I forgot to mention, I have one more problem. Since I call mmap on
>> driver initialization (thus before any rtdm_dev_open), I do not have any
>> rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>> this will work. Maybe mmap needs the 'current' struct of the user
>> program... I don't know this very well... If that is true, so I'll have
>> to do the maps in a non-rt context anyway...
>
>You cannot mmap before you know precisely for which user this should
>take place.

Do you mean that if I use the 'current' and current->mm struct of the drive=
r,
when mmaping, the user won't be able to use the returned pointer?

>During init, it's the insmod/modprobe process - likely not
>the one you are interested in.

Actually, that is the way I was planning for making the maping in a
deterministic way...

>So the earliest point for mmap is device
>open. If this is too late for you, then now finally forget about this
>pre-mmapping and turn it into a normal function for secondary mode. It
>will be hard anyway to find a user who will notice the difference.

That is not a question of noting any difference or not... An application can
works great most of the time but it can fail under some not common
circunstances. The user will need to know, at least, that he will can not
rely on rt-capabilities when doing that and will be forced to do that only =
on
initialization. But that is ok for most cases. I think I'll do that (I do n=
ot
have other options at all :) ).

Thanks,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Philippe Gerum]

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
> 
>>Rodrigo Rosenfeld Rosas wrote:
>>
>>>Jan Kiszka escreveu:
>>>
>>>>Rodrigo Rosenfeld Rosas wrote:
>>>>
>>>>>Jan Kiszka escreveu:
>>>>>
>>>>>>Ok, but even if you decide to let rt-mmap be non-deterministic, you
>>>>>>still need some means to prevent the scenario you described above.
>>>>>>Actually, all you need is some callback when the mapped memory block
>>>>>>was
>>>>>>actually released (munmap/application exit). Such a callback can be
>>>>>>registered inside the rtdm_mmap handler as a vma_fileop.
>>>>>
>>>>>I have never worked with vma_fileop... I would need to learn it first.
>>>>
>>>>Here is the patch to offer you access to those ops. Revert the previous
>>>>version, then apply this one.
>>>
>>>Actually I would have to revert the modifications I had to do for the
>>>patch to apply (some rejected chunks). But I think I'll update to the
>>>last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2
>>>xenomai? Or it would apply for all of them?
>>
>>Developed and tested against 2.1. The current patch will not cleanly
>>apply against 2.0.
> 
> 
> Ok, it already applied cleanly on last svn version. I'll reboot my computer
> and test it. That is something I didn't like in 2.1 series... I always have
> to recompile the kernel and to reboot when a new xenomai release is available
> (unless I'm missing something)... On the previous series I just compiled it
> as modules and it was only necessary to recompile the kernel when a new adeos
> (ipipe) version was available...

What about building the Xenomai support as modules instead of statically into the 
kernel?

> 
> 
>>>>It still needs some final documentation
>>>>notes and a test on kernel 2.4. But is should already work on 2.6.
>>>
>>>I forgot to mention, I have one more problem. Since I call mmap on
>>>driver initialization (thus before any rtdm_dev_open), I do not have any
>>>rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>>>this will work. Maybe mmap needs the 'current' struct of the user
>>>program... I don't know this very well... If that is true, so I'll have
>>>to do the maps in a non-rt context anyway...
>>
>>You cannot mmap before you know precisely for which user this should
>>take place.
> 
> 
> Do you mean that if I use the 'current' and current->mm struct of the driver,
> when mmaping, the user won't be able to use the returned pointer?
> 
> 
>>During init, it's the insmod/modprobe process - likely not
>>the one you are interested in.
> 
> 
> Actually, that is the way I was planning for making the maping in a
> deterministic way...
> 
> 
>>So the earliest point for mmap is device
>>open. If this is too late for you, then now finally forget about this
>>pre-mmapping and turn it into a normal function for secondary mode. It
>>will be hard anyway to find a user who will notice the difference.
> 
> 
> That is not a question of noting any difference or not... An application can
> works great most of the time but it can fail under some not common
> circunstances. The user will need to know, at least, that he will can not
> rely on rt-capabilities when doing that and will be forced to do that only on
> initialization. But that is ok for most cases. I think I'll do that (I do not
> have other options at all :) ).
> 
> Thanks,
> 
> Rodrigo.
> 
> 		
> _______________________________________________________
> Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
> http://br.acesso.yahoo.com
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Fevereiro 2006 05:55, você escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>> I forgot to mention, I have one more problem. Since I call mmap on
>>> driver initialization (thus before any rtdm_dev_open), I do not have any
>>> rtdm_user_info_t, so I need to use current instead, but I'm not sure if
>>> this will work. Maybe mmap needs the 'current' struct of the user
>>> program... I don't know this very well... If that is true, so I'll have
>>> to do the maps in a non-rt context anyway...
>> You cannot mmap before you know precisely for which user this should
>> take place.
> 
> Do you mean that if I use the 'current' and current->mm struct of the driver,
> when mmaping, the user won't be able to use the returned pointer?

To mmap you need to know the target process, more precisely its mm. This
is typically derived from the invocation context of the service call
("current" is a pointer to the current process). But init_module runs in
the context of modprobe. Even worse, the process later opening and
mapping some buffer may not even exist at that time!

> 
>> During init, it's the insmod/modprobe process - likely not
>> the one you are interested in.
> 
> Actually, that is the way I was planning for making the maping in a
> deterministic way...
> 
>> So the earliest point for mmap is device
>> open. If this is too late for you, then now finally forget about this
>> pre-mmapping and turn it into a normal function for secondary mode. It
>> will be hard anyway to find a user who will notice the difference.
> 
> That is not a question of noting any difference or not... An application can
> works great most of the time but it can fail under some not common
> circunstances. The user will need to know, at least, that he will can not
> rely on rt-capabilities when doing that and will be forced to do that only on
> initialization. But that is ok for most cases. I think I'll do that (I do not
> have other options at all :) ).

Just place enough warning signs in your documentation around the
mmap-wrapper you provide, saying that no one should expect bounded
delays from this service.

Jan


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

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:

>...
>>> You cannot mmap before you know precisely for which user this should
>>> take place.
>>
>> Do you mean that if I use the 'current' and current->mm struct of the
>> driver, when mmaping, the user won't be able to use the returned pointer?
>
>To mmap you need to know the target process, more precisely its mm. This
>is typically derived from the invocation context of the service call
>("current" is a pointer to the current process). But init_module runs in
>the context of modprobe. Even worse, the process later opening and
>mapping some buffer may not even exist at that time!

Right, I've already verified this on practice... I'm mmaping on open handle=
r=20
for now just for testing the mmap, but I'll change it to the ioctl mmap=20
handler.

It seems to work. I mapped high_memory and could read and modify it from us=
er=20
space. The memory values mantained betweens the many open calls. I read,=20
printed the values and increment them by one. On next time, the value shown=
=20
was incremented... All seems perfect but I still didn't test with real=20
acquire code... When I do so, I'll let you know.

I still need to test the vmaops. I think I'll test them tomorrow. I need to=
=20
begin writing an article that my advisor asked me to. I need to finish it=20
until march, 10.

Best Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap

[Rodrigo Rosenfeld Rosas]

Em Quarta 15 Fevereiro 2006 12:53, Rodrigo Rosenfeld Rosas escreveu:

>Em Ter=E7a 14 Fevereiro 2006 22:30, Jan Kiszka escreveu:
>>...
>>
>>>> You cannot mmap before you know precisely for which user this should
>>>> take place.
>>>
>>> Do you mean that if I use the 'current' and current->mm struct of the
>>> driver, when mmaping, the user won't be able to use the returned pointe=
r?
>>
>>To mmap you need to know the target process, more precisely its mm. This
>>is typically derived from the invocation context of the service call
>>("current" is a pointer to the current process). But init_module runs in
>>the context of modprobe. Even worse, the process later opening and
>>mapping some buffer may not even exist at that time!
>
>Right, I've already verified this on practice... I'm mmaping on open handl=
er
>for now just for testing the mmap, but I'll change it to the ioctl mmap
>handler.
>
>It seems to work. I mapped high_memory and could read and modify it from
> user space. The memory values mantained betweens the many open calls. I
> read, printed the values and increment them by one. On next time, the val=
ue
> shown was incremented... All seems perfect but I still didn't test with
> real acquire code... When I do so, I'll let you know.
>
>I still need to test the vmaops. I think I'll test them tomorrow. I need to
>begin writing an article that my advisor asked me to. I need to finish it
>until march, 10.

Ok, I tested the vmaops too and it also worked as expected. I think you cou=
ld=20
merge rtdm_mmap and related stuff to mainline RTDM. Thank you for your=20
precious work. Unfortunately you'll need to wait a while until I test them =
on=20
the real video driver. I had to stop working on it for writing the article.=
=20
When I finish the article I'll test them on real hardware but I see no=20
reasons for not working...

Best Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

[Xenomai-help] rtdm_mmap_to_user()

[Alessio Igor Bogani]

Hi All,

Someone can post on mailing-list a simple usage example of
rtdm_mmap_to_user()?
Thanks.

Best Regards,
Alessio Igor Bogani

Re: [Xenomai-help] rtdm_mmap_to_user()

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Hi Alessio, Jan has already provided such example on the list.
> 
> For your easy, I'm re-sending it to you.
> 

Yep, just ignore the patch.

Hannes has prepared some demo driver which I promised to review - I
still haven't done this :-(. But we already identified one pitfall in my
demo: before freeing the shared memory block again, you should call
ClearPageReserved analogously to SetPageReserved.

...
>> ------------------------------------------------------------------------
>>
>> #include <linux/mman.h>
>>
>> #include <rtdm/rtdm_driver.h>
>>
>>
>> #define BUFFER_SIZE     100000
>>
>>
>> struct demodrv_context {
>>     void *buf;
>> };
>>
>>
>> static void demo_vm_close(struct vm_area_struct *vma)
>> {
>>     printk("releasing %p, data = %p\n", vma, vma->vm_private_data);
>> }
>>

This hook is useful to detect when the user voluntarily released the
last reference to the mapped block. Alternative, you can rip it away via
rtdm_munmap (e.g. on device close). Just avoid freeing the memory from
kernel space as long as it's mapped and the user has a reference.

>>
>> static struct vm_operations_struct mmap_ops = {
>>     .close = demo_vm_close,
>> };
>>
>>
>> int demo_open_rt(struct rtdm_dev_context    *context,
>>                  rtdm_user_info_t           *user_info,
>>                  int                        oflags)
>> {
>>     struct demodrv_context  *my_context;
>>     unsigned long vaddr;
>>
>>
>>     my_context = (struct demodrv_context *)context->dev_private;
>>
>>     my_context->buf = kmalloc(BUFFER_SIZE, 0);
>>     /* mark pages reserved so that remap_pfn_range works */
>>     for (vaddr = (unsigned long)my_context->buf;
>>          vaddr < (unsigned long)my_context->buf + BUFFER_SIZE;
>>          vaddr += PAGE_SIZE)
>>         SetPageReserved(virt_to_page(vaddr));
>>     *(int *)my_context->buf = 1234;
>>
>>     return 0;
>> }
>>
>>
>> int demo_close_rt(struct rtdm_dev_context   *context,
>>                   rtdm_user_info_t          *user_info)
>> {
>>     struct demodrv_context  *my_context;
>>
>>
>>     my_context = (struct demodrv_context *)context->dev_private;
>>
>>     printk("%d\n", *((int *)my_context->buf + 1000));
>>

Here is that ClearPageReserved missing...

>>     kfree(my_context->buf);
>>
>>     return 0;
>> }
>>
>>
>> int demo_ioctl_rt(struct rtdm_dev_context   *context,
>>                   rtdm_user_info_t          *user_info,
>>                   int                       request,
>>                   void                      *arg)
>> {
>>     struct demodrv_context  *my_context;
>>     int err;
>>
>>
>>     my_context = (struct demodrv_context *)context->dev_private;
>>
>>     printk("buf = %p:%x\n", my_context->buf, *(int *)my_context->buf);
>>
>>     err = rtdm_mmap_to_user(user_info, my_context->buf, BUFFER_SIZE,
>>                             PROT_READ|PROT_WRITE, (void **)arg, &mmap_ops,
>>                             0x12345678);
>>     printk("rtdm_mmap = %p %d\n", *(void **)arg, err);
>>
>>     return 0;
>> }
>>
>>
>> static struct rtdm_device demo_device = {
>>     struct_version:     RTDM_DEVICE_STRUCT_VER,
>>
>>     device_flags:       RTDM_NAMED_DEVICE,
>>     context_size:       sizeof(struct demodrv_context),
>>     device_name:        "demodev0",
>>
>>     open_rt:            NULL,
>>     open_nrt:           demo_open_rt,
>>
>>     ops: {
>>         close_rt:       NULL,
>>         close_nrt:      demo_close_rt,
>>
>>         ioctl_rt:       NULL,
>>         ioctl_nrt:      demo_ioctl_rt,
>>
>>         read_rt:        NULL,
>>         read_nrt:       NULL,
>>
>>         write_rt:       NULL,
>>         write_nrt:      NULL,
>>
>>         recvmsg_rt:     NULL,
>>         recvmsg_nrt:    NULL,
>>
>>         sendmsg_rt:     NULL,
>>         sendmsg_nrt:    NULL,
>>     },
>>
>>     device_class:       RTDM_CLASS_EXPERIMENTAL,
>>     device_sub_class:   222,
>>     driver_name:        "demodrv",
>>     peripheral_name:    "demodev",
>>     provider_name:      "-",
>>     proc_name:          demo_device.device_name,
>> };
>>
>> int init_module(void)
>> {
>>     int ret;
>>
>>
>>     ret = rtdm_dev_register(&demo_device);
>>     printk("rtdm_dev_register = %d\n", ret);
>>
>>     return ret;
>> }
>>
>>
>> void cleanup_module(void)
>> {
>>     rtdm_dev_unregister(&demo_device, 1000);
>> }
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help

Jan


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

[Xenomai-core] RTDM w/MMAP demo online (was: Re: [Xenomai-help] rtdm_mmap_to_user()

[Hannes Mayer]

Ciao Jan et al.!

Jan Kiszka wrote:
[...]
> ClearPageReserved analogously to SetPageReserved.

Yeah, that did the trick! If one opens a door, a polite guy
also close it again ;-)

My RTDM demo driver is now online at:
http://www.captain.at/xenomai-real-time-driver-example.php

I've also modified user.c - now I'll check if the user has
interrupted the user-app (i.e. the device was closed) to
avoid segfaulting when accessing the MMAP pointer after the
dev was closed.

Comments, corrections, exhancements etc. very welcome!

Thanks and best regards,
Hannes.