[Xenomai-help] RTDM mmap alternative

[Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Hi Jan, I'm back on this discussion.

At the time I asked you, you told me to do the mmap on driver initialization.

But now, I realized that, since I'll be using RTDM, how could I use mmap from RTDM, even if in a
non RT-context?

I'm a bit confusing...

What would be others alternatives for avoid copying the video frames in a RTDM driver?

Thanks,

Rodrigo.



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

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, I'm back on this discussion.
> 
> At the time I asked you, you told me to do the mmap on driver
> initialization.
> 
> But now, I realized that, since I'll be using RTDM, how could I use
> mmap from RTDM, even if in a non RT-context?

Which mapping step are you now referring to, the one to get the large
physical DMA area inside the kernel address space or the one to map
kernel addresses to user space? Already checked the related LDD3 chapter
for this?

> 
> I'm a bit confusing...
> 
> What would be others alternatives for avoid copying the video frames
> in a RTDM driver?

Either map or copy, there is no third way. The point is just which
mapping functions to use and when.

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Hi, Jan. I think I wasn't very clear on my post. I'll try to clarify 
what I meaned...

Jan Kiszka escreveu:
> Rodrigo Rosenfeld Rosas wrote:
>   
>> Hi Jan, I'm back on this discussion.
>>
>> At the time I asked you, you told me to do the mmap on driver
>> initialization.
>>
>> But now, I realized that, since I'll be using RTDM, how could I use
>> mmap from RTDM, even if in a non RT-context?
>>     
>
> Which mapping step are you now referring to, the one to get the large
> physical DMA area inside the kernel address space or the one to map
> kernel addresses to user space?
I'm refering to the second case. I want to map the kernel addresses to 
user space but I'm not very sure if I can do the same thing I did in my 
previous mmap call on an ioctl. I mean, I don't know if the kernel does 
something else in a mmap call... And since I don't have a mmap handler 
I'm a bit confusing...

>  Already checked the related LDD3 chapter for this?
>   
Yes, but it didn't answered to my doubts...
>> I'm a bit confusing...
>>
>> What would be others alternatives for avoid copying the video frames
>> in a RTDM driver?
>>     
>
> Either map or copy, there is no third way. The point is just which
> mapping functions to use and when.
>   
That is what I would like to know... Which mapping functions are 
available? Actually, if I can use the same I used on my previous mmap 
handler that is good. I'm just unsure if something will be missing or not...

I have also noted that there is no poll or select handler on RTDM. Are 
there some plans to include them?

Thank you,

Rodrigo.


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

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Hi, Jan. I think I wasn't very clear on my post. I'll try to clarify
> what I meaned...
> 
> Jan Kiszka escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>  
>>> Hi Jan, I'm back on this discussion.
>>>
>>> At the time I asked you, you told me to do the mmap on driver
>>> initialization.
>>>
>>> But now, I realized that, since I'll be using RTDM, how could I use
>>> mmap from RTDM, even if in a non RT-context?
>>>     
>>
>> Which mapping step are you now referring to, the one to get the large
>> physical DMA area inside the kernel address space or the one to map
>> kernel addresses to user space?
> I'm refering to the second case. I want to map the kernel addresses to
> user space but I'm not very sure if I can do the same thing I did in my
> previous mmap call on an ioctl. I mean, I don't know if the kernel does
> something else in a mmap call... And since I don't have a mmap handler
> I'm a bit confusing...
> 
>>  Already checked the related LDD3 chapter for this?
>>   
> Yes, but it didn't answered to my doubts...

What precisely? I suggested to look at remap_pfn_range() or
io_remap_page_range(). Do you see problems when using one of them?

>>> I'm a bit confusing...
>>>
>>> What would be others alternatives for avoid copying the video frames
>>> in a RTDM driver?
>>>     
>>
>> Either map or copy, there is no third way. The point is just which
>> mapping functions to use and when.
>>   
> That is what I would like to know... Which mapping functions are
> available? Actually, if I can use the same I used on my previous mmap
> handler that is good. I'm just unsure if something will be missing or
> not...

As I haven't written such a driver as well yet, I cannot say which one
will fit. You will have to go though the LDD explanations and play with
it (which means e.g. finding out where to obtain all required arguments
- should be feasible).

> 
> I have also noted that there is no poll or select handler on RTDM. Are
> there some plans to include them?
> 

Only rough plans. This requires a lot of work and restructuring, I'm
afraid. And I doubt that it's worth it. Do you see an urgent use-case
for poll/select under RT? The only real-life use-case that we came
across was ACE/TAO.

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Jan Kiszka escreveu:
> ...
>  I suggested to look at remap_pfn_range() or
> io_remap_page_range(). Do you see problems when using one of them?
>   
Ok, I'll try them on an ioctl on monday. I'll let you know then.
> ...
>> I have also noted that there is no poll or select handler on RTDM. Are
>> there some plans to include them?
>>     
> Only rough plans. This requires a lot of work and restructuring, I'm
> afraid. And I doubt that it's worth it. Do you see an urgent use-case
> for poll/select under RT? The only real-life use-case that we came
> across was ACE/TAO.
>   
I was thinking of providing an API similar to v4l2 on my RTDM video 
driver. But since it does not have neither mmap nor select/poll, I'll 
have to do all these tasks by ioctl... But that is no problem at all. 
There will not be missing any feature but the v4l2 compatibility...

Thank you for all support you are giving me.

Best regards,

Rodrigo.


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Hi Jan,

>...
>What precisely? I suggested to look at remap_pfn_range() or
>io_remap_page_range(). Do you see problems when using one of them?

This is the function prototype:

int remap_pfn_range(struct vm_area_struct *vma,
unsigned long virt_addr, unsigned long pfn,
unsigned long size, pgprot_t prot);

When a mmap call is issued, the vma structure is already initially filled. =
I=20
don't know how to fill it and LDD3 doesn't explain it:

"The arguments to remap_pfn_range are fairly straightforward, and most of t=
hem=20
are already provided to you in the VMA when your mmap method is called."

"Note that the kernel maintains lists and trees of VMAs to optimize area=20
lookup, and several fields of vm_area_struct are used to maintain this=20
organization. Therefore, VMAs can=E2=80=99t be created at will by a driver,=
 or the=20
structures break."

So, I don't know how to implement a mmap like ioctl. Any sugestions?

Thanks,

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Fa�a do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 2242 bytes --]

[snmp on web.de down, switching account]

Rodrigo Rosenfeld Rosas wrote:
> Hi Jan,
> 
>> ...
>> What precisely? I suggested to look at remap_pfn_range() or
>> io_remap_page_range(). Do you see problems when using one of them?
> 
> This is the function prototype:
> 
> int remap_pfn_range(struct vm_area_struct *vma,
> unsigned long virt_addr, unsigned long pfn,
> unsigned long size, pgprot_t prot);
> 
> When a mmap call is issued, the vma structure is already initially filled. I 
> don't know how to fill it and LDD3 doesn't explain it:
> 
> "The arguments to remap_pfn_range are fairly straightforward, and most of them 
> are already provided to you in the VMA when your mmap method is called."
> 
> "Note that the kernel maintains lists and trees of VMAs to optimize area 
> lookup, and several fields of vm_area_struct are used to maintain this 
> organization. Therefore, VMAs can?t be created at will by a driver, or the 
> structures break."
> 
> So, I don't know how to implement a mmap like ioctl. Any sugestions?
> 

Well, I have to say sorry. I was obviously too optimistic about an easy
way to implement mmap-features outside a mmap handler. It's far more
complex.

Ok, we need some helper function in RTDM to make life easier for
driver developers. Attached is a draft to implement

void *rtdm_mmap_to_user(void *buffer, size_t length);

It can only be invoked on continuous kernel memory (kmalloc'ed or
ioremap'ped), but this should be sufficient for the intended
applications. And it only runs in Linux context of course.

I tested it (after figuring out what to do at all, and how to get it
working then...) with a simple demo that returns a shared kernel memory
block, mapped into user-space via an RTDM-IOCTL. I think you should
easily (now really!) adapt it to your needs. Please check if this
functions meets your requirements and works for more than one scenario.
If so, I will add it to official RTDM.


@all: I would be curious to hear any comment on my /dev/zero-trick to
invoke mmap in kernel-space. Is this an ugly hack or may it be worth
considering to apply on /dev/rtheap as well - to overcome the need for
this device (and related user errors...)?

Jan

[-- Attachment #1.2: rtmmap_drv.c --]
[-- Type: text/plain, Size: 4219 bytes --]

#include <linux/mman.h>

#define XENO_HEAP_MODULE
#include <asm-generic/system.h>
#include <rtdm/rtdm_driver.h>


#define BUFFER_SIZE     100000


struct demodrv_context {
    void *buf;
};


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));

    kfree(my_context->buf);

    return 0;
}


/* *** RTDM mmap helper *** */

static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma)
{
    return xnarch_remap_page_range(vma, vma->vm_start,
                                   virt_to_phys(filp->private_data),
                                   vma->vm_end - vma->vm_start, PAGE_SHARED);
    return 0;
}


static struct file_operations rtdm_mmap_fops = {
    .mmap = rtdm_mmap_buffer,
};


void *rtdm_mmap_to_user(void *buffer, size_t length)
{
    struct file *filp;
    struct file_operations *old_fops;
    void *old_priv_data;
    void *user_addr;

    filp = filp_open("/dev/zero", O_RDWR, 0);
    if (IS_ERR(filp)) {
        printk("open failed\n");
        return filp;
    }

    old_fops = filp->f_op;
    filp->f_op = &rtdm_mmap_fops;

    old_priv_data = filp->private_data;
    filp->private_data = buffer;

    down_write(&current->mm->mmap_sem);
    user_addr = (void *)do_mmap(filp, 0, length, PROT_READ|PROT_WRITE, MAP_SHARED, 0);
    up_write(&current->mm->mmap_sem);

    filp->f_op = old_fops;
    filp->private_data = old_priv_data;

    filp_close(filp, current->files);

    return user_addr;
}

/* *** End of RTDM mmap helper *** */


int demo_ioctl_rt(struct rtdm_dev_context   *context,
                  rtdm_user_info_t          *user_info,
                  int                       request,
                  void                      *arg)
{
    struct demodrv_context  *my_context;


    my_context = (struct demodrv_context *)context->dev_private;

    printk("buf = %p:%x\n", my_context->buf, *(int *)my_context->buf);

    *(void **)arg = rtdm_mmap_to_user(my_context->buf, BUFFER_SIZE);
    printk("rtdm_mmap = %p %d\n", *(void **)arg, *(int *)arg);

    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);
}


[-- Attachment #1.3: rtmmap.c --]
[-- Type: text/plain, Size: 385 bytes --]

#include <stdio.h>
#include <unistd.h>
#include <rtdm/rtdm.h>

int main()
{
    int f = rt_dev_open("demodev0", 0);
    void *p;
    printf("open = %d\n", f);
    printf("ioctl = %d\n", rt_dev_ioctl(f, 0, &p));
    printf("*p = %d, p = %p\n", *((int *)p), p);
    sleep(10);
    *((int *)p + 1000) = 5678;
    printf("close = %d\n", rt_dev_close(f));
    return 0;
}


[-- Attachment #1.4: GNUmakefile --]
[-- Type: text/plain, Size: 217 bytes --]

all:
	make -C /usr/src/linux-2.6.14-ipipe SUBDIRS=/usr/src/rtmmap modules
	gcc -o rtmmap rtmmap.c `/usr/src/xenomai/bin/bin/xeno-config --xeno-cflags` `/usr/src/xenomai/bin/bin/xeno-config --xeno-ldflags` -lrtdm


[-- Attachment #1.5: Makefile --]
[-- Type: text/plain, Size: 91 bytes --]

EXTRA_CFLAGS += -I /usr/src/linux-2.6.14-ipipe/include/xenomai

obj-m += rtmmap_drv.o


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Hi Jan, thank you for your precious code! :)

But, while it is executed in Linux context, ie, in a non-rt context, I coul=
d=20
register a normal Linux file descriptor and call mmap on it. Or I could mma=
p=20
the device /dev/mem for mapping the memory region I would need. I can obtai=
n=20
the absolute address from a RTDM ioctl call.

Anyway, I'll be missing the V4L2 compatibility but that is not a great issu=
e.=20
But since I only need to call this on initialization, I don't need to be in=
=20
RT-context in my specific application. But since I'm also developing a=20
robotic programming framework it would be nice to have this mmap capability=
=20
in real-time context.

But thank you anyway. I really appreciate your code.

Best regards,

Rodrigo.

____________________________________________________________
Em Ter=E7a 07 Fevereiro 2006 15:38, Jan Kiszka escreveu:

>[snmp on web.de down, switching account]
>
>Rodrigo Rosenfeld Rosas wrote:
>> Hi Jan,
>>
>>> ...
>>> What precisely? I suggested to look at remap_pfn_range() or
>>> io_remap_page_range(). Do you see problems when using one of them?
>>
>> This is the function prototype:
>>
>> int remap_pfn_range(struct vm_area_struct *vma,
>> unsigned long virt_addr, unsigned long pfn,
>> unsigned long size, pgprot_t prot);
>>
>> When a mmap call is issued, the vma structure is already initially fille=
d.
>> I don't know how to fill it and LDD3 doesn't explain it:
>>
>> "The arguments to remap_pfn_range are fairly straightforward, and most of
>> them are already provided to you in the VMA when your mmap method is
>> called."
>>
>> "Note that the kernel maintains lists and trees of VMAs to optimize area
>> lookup, and several fields of vm_area_struct are used to maintain this
>> organization. Therefore, VMAs can?t be created at will by a driver, or t=
he
>> structures break."
>>
>> So, I don't know how to implement a mmap like ioctl. Any sugestions?
>
>Well, I have to say sorry. I was obviously too optimistic about an easy
>way to implement mmap-features outside a mmap handler. It's far more
>complex.
>
>Ok, we need some helper function in RTDM to make life easier for
>driver developers. Attached is a draft to implement
>
>void *rtdm_mmap_to_user(void *buffer, size_t length);
>
>It can only be invoked on continuous kernel memory (kmalloc'ed or
>ioremap'ped), but this should be sufficient for the intended
>applications. And it only runs in Linux context of course.
>
>I tested it (after figuring out what to do at all, and how to get it
>working then...) with a simple demo that returns a shared kernel memory
>block, mapped into user-space via an RTDM-IOCTL. I think you should
>easily (now really!) adapt it to your needs. Please check if this
>functions meets your requirements and works for more than one scenario.
>If so, I will add it to official RTDM.
>
>
>@all: I would be curious to hear any comment on my /dev/zero-trick to
>invoke mmap in kernel-space. Is this an ugly hack or may it be worth
>considering to apply on /dev/rtheap as well - to overcome the need for
>this device (and related user errors...)?
>
>Jan

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

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Hi Jan, thank you for your precious code! :)
> 
> But, while it is executed in Linux context, ie, in a non-rt context, I could 
> register a normal Linux file descriptor and call mmap on it. Or I could mmap 

You still need the back-end, i.e. some Linux device being registered and
catch your mmap call. That's how /dev/rtheap e.g. works.

> the device /dev/mem for mapping the memory region I would need. I can obtain 
> the absolute address from a RTDM ioctl call.

/dev/mem is all or nothing: once you allow access, you cannot control
which memory region gets mapped. Closing this loop in kernel space
produces safer code with the option to get it even secure one day
(current Xenomai APIs do not address the latter aspect yet).

> 
> Anyway, I'll be missing the V4L2 compatibility but that is not a great issue. 

You mean some kind of rt_dev_mmap(..., rt-fildes, ...) (or wrapped mmap
in the posix skin)? We could define a standard RTDM-IOCTL and write the
user-space lib functions so that interested drivers can receive such
requests in a canonical way. The implementation in the driver would
still be different to Linux (just rtdm_mmap_to_user, no page-on-demand
e.g.).

> But since I only need to call this on initialization, I don't need to be in 
> RT-context in my specific application. But since I'm also developing a 
> robotic programming framework it would be nice to have this mmap capability 
> in real-time context.

Dynamic mmap'ping in RT is contradictory: Touching your current process'
mm creates dependencies on a lot of kernel code paths that can modify it
as well - if such modifications can be made deterministic at all in
Linux. But I guess you don't means this. Even V4L2 mmap's only during
init and not during the critical capturing process - it's far to slow.

You know that, due to Xenomai's automatic mode switching, you would be
free to call such rt_dev_mmap even from RT tasks? It would just switch
you temporarily over.

> 
> But thank you anyway. I really appreciate your code.
> 
> Best regards,
> 
> Rodrigo.
> 

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Jan Kiszka escreveu:
> Rodrigo Rosenfeld Rosas wrote:
>   
>> Hi Jan, thank you for your precious code! :)
>>
>> But, while it is executed in Linux context, ie, in a non-rt context, I could 
>> register a normal Linux file descriptor and call mmap on it. Or I could mmap 
>>     
>
> You still need the back-end, i.e. some Linux device being registered and
> catch your mmap call. That's how /dev/rtheap e.g. works.
>   
I know. I would register as something like "/dev/rtvideo".
>> the device /dev/mem for mapping the memory region I would need. I can obtain 
>> the absolute address from a RTDM ioctl call.
>>     
> /dev/mem is all or nothing: once you allow access, you cannot control
> which memory region gets mapped. Closing this loop in kernel space
> produces safer code with the option to get it even secure one day
> (current Xenomai APIs do not address the latter aspect yet).
>   
I know it is better but it will require extra effort from my part and 
will be only temporary...
>> Anyway, I'll be missing the V4L2 compatibility but that is not a great issue. 
>>     
> You mean some kind of rt_dev_mmap(..., rt-fildes, ...) (or wrapped mmap
> in the posix skin)?
Yes, I would like to use rt_dev_mmap... But I would be fine if I just 
could do it anyway in RT-context...
>  We could define a standard RTDM-IOCTL and write the
> user-space lib functions so that interested drivers can receive such
> requests in a canonical way.
I really don't need the user-space lib functions and don't think others 
will need it too... I would be just fine with a RTDM-IOCTL if it was in 
RT-context...
>  The implementation in the driver would
> still be different to Linux (just rtdm_mmap_to_user, no page-on-demand
> e.g.).
>   
It will be different anyway as I'll be using rt_dev_open etc, but it 
will be analogue to the ones used by V4L2. And I think very few people 
would need the page-on-demand feature...
>> But since I only need to call this on initialization, I don't need to be in 
>> RT-context in my specific application. But since I'm also developing a 
>> robotic programming framework it would be nice to have this mmap capability 
>> in real-time context.
>>     
> Dynamic mmap'ping in RT is contradictory: Touching your current process'
> mm creates dependencies on a lot of kernel code paths that can modify it
> as well - if such modifications can be made deterministic at all in
> Linux.
Unfortunately my knowledge of how linux deals with vma is very 
limited... Actually, my knowledge of how memory access is made by the 
processor is very limited too. I know that there are protected memory 
and virtual memory but I'm not confortable with how it is achieved nor 
by the processor nor by Linux. If it is too difficult to make it 
deterministic, so I won't expect mmap to be made RT soon... Fortunately 
I don't really need it for now.
> But I guess you don't means this.
Actually I did. But, as I said, I don't really need it. It would just be 
nice to provide this option in my framework...
> Even V4L2 mmap's only during
> init and not during the critical capturing process - it's far to slow.
>   
I was not thinking in doing the mmap during the critical capturing 
process, but maybe during a reconfiguration of the system by some reason...
> You know that, due to Xenomai's automatic mode switching, you would be
> free to call such rt_dev_mmap even from RT tasks? It would just switch
> you temporarily over.
>   
Yes, but I couldn't use it in hard real-time tasks... It is dangerous to 
switch to secondary mode by a task of high priority... As I've said, I 
don't know, from the moment, some real case where it would be necessary 
to do so, but since I'm developing a framework, it would be nice to 
provide this option...

Thank you for your concerns,

Best wishes,

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

>...
>I tested it (after figuring out what to do at all, and how to get it
>working then...) with a simple demo that returns a shared kernel memory
>block, mapped into user-space via an RTDM-IOCTL. I think you should
>easily (now really!) adapt it to your needs. Please check if this
>functions meets your requirements and works for more than one scenario.
>If so, I will add it to official RTDM.
>
>
>@all: I would be curious to hear any comment on my /dev/zero-trick to
>invoke mmap in kernel-space. Is this an ugly hack or may it be worth
>considering to apply on /dev/rtheap as well - to overcome the need for
>this device (and related user errors...)?

Jan, actually I didn't like the /dev/zero hack. If someone else is 
using /dev/zero it will result in a problem... I think it would be better to 
reserve a separate file descriptor for mmaping. Maybe in a separate module 
like xeno_mmap that only register a, say, /dev/xenommap or /dev/xenomai/mmap. 
I think it would be a better approach. Or maybe something like 

void *rtdm_mmap_to_user(void *buffer, size_t length, char *dev_to_use)

Just some ideas...

Rodrigo.

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

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
>> ...
>> I tested it (after figuring out what to do at all, and how to get it
>> working then...) with a simple demo that returns a shared kernel memory
>> block, mapped into user-space via an RTDM-IOCTL. I think you should
>> easily (now really!) adapt it to your needs. Please check if this
>> functions meets your requirements and works for more than one scenario.
>> If so, I will add it to official RTDM.
>>
>>
>> @all: I would be curious to hear any comment on my /dev/zero-trick to
>> invoke mmap in kernel-space. Is this an ugly hack or may it be worth
>> considering to apply on /dev/rtheap as well - to overcome the need for
>> this device (and related user errors...)?
> 
> Jan, actually I didn't like the /dev/zero hack. If someone else is 
> using /dev/zero it will result in a problem... I think it would be better to 

Why? It isn't an exclusive device. And I'm only invoking open/close on
the original instance (which even have no handlers associated, see
drivers/char/mem.c), mmap gets overloaded.

> reserve a separate file descriptor for mmaping. Maybe in a separate module 
> like xeno_mmap that only register a, say, /dev/xenommap or /dev/xenomai/mmap. 
> I think it would be a better approach. Or maybe something like 
> 
> void *rtdm_mmap_to_user(void *buffer, size_t length, char *dev_to_use)
> 
> Just some ideas...

Maybe I'm overseeing something: Did you face real problems with my approach?

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Em Quarta 08 Fevereiro 2006 11:14, Jan Kiszka escreveu:

>> ...
>> Jan, actually I didn't like the /dev/zero hack. If someone else is
>> using /dev/zero it will result in a problem... I think it would be better
>> to
>
>Why? It isn't an exclusive device. And I'm only invoking open/close on
>the original instance (which even have no handlers associated, see
>drivers/char/mem.c), mmap gets overloaded.

I'm a little confused here. I noted you have made a backup of the 
file_operations struct and private_data. So, I've concluded, wrongly, that 
those handlers would be used by every process that called that open handler. 
But, looking at the mem.c code, I think that those data (file_ops and 
private_data) are different structs each time the user issues a call to open. 
If that is true, I don't see any problem in using your approach. But I don't 
see neither any needs for making that backup...

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Quarta 08 Fevereiro 2006 11:14, Jan Kiszka escreveu:
> 
>>> ...
>>> Jan, actually I didn't like the /dev/zero hack. If someone else is
>>> using /dev/zero it will result in a problem... I think it would be better
>>> to
>> Why? It isn't an exclusive device. And I'm only invoking open/close on
>> the original instance (which even have no handlers associated, see
>> drivers/char/mem.c), mmap gets overloaded.
> 
> I'm a little confused here. I noted you have made a backup of the 
> file_operations struct and private_data. So, I've concluded, wrongly, that 
> those handlers would be used by every process that called that open handler. 
> But, looking at the mem.c code, I think that those data (file_ops and 
> private_data) are different structs each time the user issues a call to open. 

Yep, that's the point. Actually, I was inspired by some other mmap'ing
driver which does a similar overloading on it's own device type.

> If that is true, I don't see any problem in using your approach. But I don't 
> see neither any needs for making that backup...

On first sight this is true and the backup is redundant. But it is
cleaner to not rely on a specific kernel implementation. Instead it's
saner to look at the model: I'm changing the fops without knowing what
the open handler did, so make sure that a possible release handler can
run. And this is also not very costly here. :)

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Em Quarta 08 Fevereiro 2006 16:26, Jan Kiszka escreveu:

>>>> ...
>>>> Jan, actually I didn't like the /dev/zero hack. If someone else is
>>>> using /dev/zero it will result in a problem... I think it would be
>>>> better to
>>>
>>> Why? It isn't an exclusive device. And I'm only invoking open/close on
>>> the original instance (which even have no handlers associated, see
>>> drivers/char/mem.c), mmap gets overloaded.
>>
>> I'm a little confused here. I noted you have made a backup of the
>> file_operations struct and private_data. So, I've concluded, wrongly, that
>> those handlers would be used by every process that called that open
>> handler. But, looking at the mem.c code, I think that those data (file_ops
>> and private_data) are different structs each time the user issues a call
>> to open.
>
>Yep, that's the point. Actually, I was inspired by some other mmap'ing
>driver which does a similar overloading on it's own device type.
>
>> If that is true, I don't see any problem in using your approach. But I
>> don't see neither any needs for making that backup...
>
>On first sight this is true and the backup is redundant. But it is
>cleaner to not rely on a specific kernel implementation.

But if the kernel implementation will change it won't be safer to operate this 
way... Because someone else could try to use the /dev/zero while you changed 
the handlers... If this happens some day, you could change /dev/zero to some 
file descriptor or your own then.

>Instead it's 
>saner to look at the model: I'm changing the fops without knowing what
>the open handler did, so make sure that a possible release handler can
>run. And this is also not very costly here. :)

Ok, I got your point. You mean if the driver rely on fops when releasing. Ok, 
I think that the approach you suggested is great. As I've said I would only 
change the return of rtdm_mmap_to_user to NULL on error. Then you could add 
it to RTDM...

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Forgot to mention that I would also return NULL on error on rtdm_mmap_to_user 
instead of returning the filp...

Rodrigo.

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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

One more doubt: how would I munmap that memory? do_munmap and passing 
current->mm as the first parameter and the physical address as start? I'm not 
sure... Maybe the user can call munmap directly since it doesn't need the 
file descriptor. But which address should (s)he pass to start parameter, the 
virtual or the physical one?

Thank you again,

Rodrigo.

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

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> One more doubt: how would I munmap that memory? do_munmap and passing 
> current->mm as the first parameter and the physical address as start? I'm not 

Yes, but better save current->mm at mmap time and pass *this* value on
unmap. I'm thinking about a way to include this in RTDM.

> sure... Maybe the user can call munmap directly since it doesn't need the 
> file descriptor. But which address should (s)he pass to start parameter, the 
> virtual or the physical one?

This is also an option. The user would have to pass the virtual address
the driver returned.

But I think we still need a cleanup on RTDM device closure to avoid
access to the mapped physical buffers after that point. I wonder how
this is done in standard drivers, will have to look at some of them.

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Em Quinta 09 Fevereiro 2006 06:53, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> One more doubt: how would I munmap that memory? do_munmap and passing
>> current->mm as the first parameter and the physical address as start? I'm
>> not
>
>Yes, but better save current->mm at mmap time and pass *this* value on
>unmap. I'm thinking about a way to include this in RTDM.

Why should I make a backup of mm? Why would it change? Just for curiosity...

>> sure... Maybe the user can call munmap directly since it doesn't need the
>> file descriptor. But which address should (s)he pass to start parameter,
>> the virtual or the physical one?
>
>This is also an option. The user would have to pass the virtual address
>the driver returned.

I'm curious. How do you know in which circunstances should one pass the 
virtual or the physical address? I never know which to use...

>But I think we still need a cleanup on RTDM device closure to avoid
>access to the mapped physical buffers after that point. I wonder how
>this is done in standard drivers, will have to look at some of them.

Sorry, I can't help here, since the user munmap don't pass through the 
driver... :( I don't know if it is even done by the drivers. The mmap man 
page states:

"The  munmap()  system  call deletes the mappings for the specified address 
range, and causes further references to addresses within the range to 
generate invalid memory references.  The region is  also automatically 
unmapped when the process is terminated.  On the other hand, closing the file 
descriptor does not unmap the region."

So, the mmap will be undone when the program finishes, I think.

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] RTDM mmap alternative

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Quinta 09 Fevereiro 2006 06:53, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> One more doubt: how would I munmap that memory? do_munmap and passing
>>> current->mm as the first parameter and the physical address as start? I'm
>>> not
>> Yes, but better save current->mm at mmap time and pass *this* value on
>> unmap. I'm thinking about a way to include this in RTDM.
> 
> Why should I make a backup of mm? Why would it change? Just for curiosity...

Because current may change, at least with the currently lacking
auto-cleanup of RT objects (including devices and sockets) on process
termination. If we then invoke an enforced closure (e.g. via "echo
<fildes> > /proc/xenomai/rtdm/open_fildes"), mm or current has to be known.

> 
>>> sure... Maybe the user can call munmap directly since it doesn't need the
>>> file descriptor. But which address should (s)he pass to start parameter,
>>> the virtual or the physical one?
>> This is also an option. The user would have to pass the virtual address
>> the driver returned.
> 
> I'm curious. How do you know in which circunstances should one pass the 
> virtual or the physical address? I never know which to use...

The user typically only knows the virtual one, at least when looking at
mmap/munmap. Only if there is some specific agreement between driver and
user (see /dev/mem), the physical address behind it may be known as
well. Still, [do_]munmap takes the virtual one.

> 
>> But I think we still need a cleanup on RTDM device closure to avoid
>> access to the mapped physical buffers after that point. I wonder how
>> this is done in standard drivers, will have to look at some of them.
> 
> Sorry, I can't help here, since the user munmap don't pass through the 
> driver... :( I don't know if it is even done by the drivers. The mmap man 
> page states:
> 
> "The  munmap()  system  call deletes the mappings for the specified address 
> range, and causes further references to addresses within the range to 
> generate invalid memory references.  The region is  also automatically 
> unmapped when the process is terminated.  On the other hand, closing the file 
> descriptor does not unmap the region."
> 
> So, the mmap will be undone when the program finishes, I think.

Indeed, this is also what I quickly verified in practice. E.g., if you
do not munmap the region I provided in my test driver, the user-space
tool will still be able to access the physical memory behind it. In that
case, the user kmalloc'ing (or whatever) that region again after a kfree
would access memory that is probably used in a totally different way
meanwhile. Dangerous!

If it is just RAM, you may track the releases (register vma_fops) and
call kfree only when the last user finished. But when it's physical
device memory, you may want to have access earlier. Thus we need
"enforced" munmap on rt_dev_close, maintained by the individual driver.
Therefore, I will introduce also rtdm_munmap() or so.

Jan


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

Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas]

Em Quinta 09 Fevereiro 2006 14:53, Jan Kiszka escreveu:

> ...
>>> But I think we still need a cleanup on RTDM device closure to avoid
>>> access to the mapped physical buffers after that point. I wonder how
>>> this is done in standard drivers, will have to look at some of them.
>>
>> Sorry, I can't help here, since the user munmap don't pass through the
>> driver... :( I don't know if it is even done by the drivers. The mmap man
>> page states:
>>
>> "The  munmap()  system  call deletes the mappings for the specified
>> address range, and causes further references to addresses within the range
>> to generate invalid memory references.  The region is  also automatically
>> unmapped when the process is terminated.  On the other hand, closing the
>> file descriptor does not unmap the region."
>>
>> So, the mmap will be undone when the program finishes, I think.
>
>Indeed, this is also what I quickly verified in practice. E.g., if you
>do not munmap the region I provided in my test driver, the user-space
>tool will still be able to access the physical memory behind it.

Even if the application was closed and then rerun using a stored address? It 
would not conform to documentations in this case... I think you're talking 
about just closing the file descriptor with rtdm_dev_close, right?

>In that case, the user kmalloc'ing (or whatever) that region again after a
>kfree would access memory that is probably used in a totally different way
>meanwhile. Dangerous!

But, anyway it would be a user error. Not a driver issue... But I agree that 
it would be great to undone the mapping on closing the file descriptor, 
although it would not be compatible with normal mmap behaviour.

>If it is just RAM, you may track the releases (register vma_fops) and
>call kfree only when the last user finished. But when it's physical
>device memory, you may want to have access earlier. Thus we need
>"enforced" munmap on rt_dev_close, maintained by the individual driver.
>Therefore, I will introduce also rtdm_munmap() or so.

It would be nice to be able to call rtdm_munmap. :)

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html