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

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

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