Re: [Xenomai-help] RTDM mmap alternative

[Rodrigo Rosenfeld Rosas <lbocseg@domain.hid>]

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