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

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

Jan Kiszka escreveu:
> ...
>> I'm not very sure about that. It can work for most situations but there
>> could be one situation where it would crash just because it was chosen
>> to have a little smaller code size and a little speed gain... I would
>> not like to think in the consequences of a crash in the driver while a
>> RT-system is working on real world...
>>     
>
> And I would not like to think of having instrumented RTOS cores and a
> drivers in the field. This would rather indicate to me that someone did
> not do his/her homework: testing and debugging the system before
> delivering it.
>   
Ok, I'm not really interested on this topic for continue discussing it. 
It is fine for me to do that checks on my own code before calling 
rtdm_mmap_to_user...
> ...
> Via any invocation, just check the handler prototypes:
> rtdm_open_handler_t, rtdm_close_handler_t, rtdm_ioctl_handler_t, ...
>   
Now I've found them! I think I was a bit lazy at that time... :) Thanks!

>>> ...  
>>>       
>> Yes, but it would be simpler for new developers used to the V4L2 API to
>> migrate to a similar RT-Video interface. Anyway, as I've already said, I
>> don't think some users would do any mmap during runtime, but maybe for
>> some reconfiguration for some reason and they would like to make this in
>> a RT-context. I can't really imagine a practical situation from the
>> moment, but I think it is still possible to happen...
>>     
>
> Ok, but then you can still offer mmap via secondary mode even to RT
> tasks.
But I would lose the determinism...
> It's a corner case, and mmap will never have a deterministic
> execution time without changing the vmm rather fundamentally, so the
> user can't expect such behaviour. If (s)he does so, the application
> design is broken anyway.
>   
I agree. That is why I'm trying to provide an alternative solution. It 
is not quite a mmap, but it is similar...

>>> ...  
>>>       
>> That is something I could change in my driver... Making the mmap on the
>> VIDIOC_REQBUFS ioctl request. But, as a driver could return a different
>> number of buffers than the requested, the user could not be satisfied
>> with the returned buffers and the mmap would have been useless... I
>> still don't know how will the final design be like, but I'm fine with
>> your already provided rtdm_mmap_to_user solution. But I still want to
>> keep the API as closer as possible to V4L2 for facilitating the users to
>> migrate to real-time while taking advantage of the already available
>> V4L2 documentation and examples all over the web and just doing the
>> minimal needed modifications.
>>     
>
> Ok, I see the idea behind it, and under those constraints it does make
> sense to provide some wrapper for mmap over the RT capturing device.
>
> ...
> I think I now got your goals completely:
>
>  1. keep the interface of V4L2
>   
... as closer as possible.
>  2. completely provide it a deterministic way
>   
I'm not really worried about that, but if I could do it in some not very 
sofisticated way, I would like to provide such behaviour. But I 
recognize that for must situations the user won't need deterministic mmap.
> I can understand the first goal. Keeping the V4L2 interface for a
> potential RTDM frame grabbing device profile can make sense if it
> doesn't complicate the rt-driver internals too much or stresses it
> rt-guarantees.
>
> But I still have some doubts that aiming for 2. regarding mmap is worth
> the effort. The problem is that you cannot predict how many buffers have
> to be pre-mapped in order to provide them with bounded delay via some
> rt-mmap. I wouldn't spent time on this.
>   
This could be another module parameter. If the user is not satisfied 
with the default limits, (s)he could override them. But I really don't 
pretend to spent more time on this... I'm very worried about my 
deadline... :( I still have too much to do in 4 months... :((
> 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.
>  It will run in
> non-RT, and could be used to mark the related hardware buffer as finally
> free for re-allocation.
Now, I did realize that there is one more problem on my current design. 
If the user application exits or is terminated, I'm not sure if the 
close handler is called if the user forgot/was not able to. If it is 
not, the buffer would be marked as used until I reloaded the driver... 
Is the close handler invocated on application termination?
> I will draft some extension of the current
> rtdm_mmap_to_user function, but likely not before tomorrow evening or so.
>   
Thank you.

Rodrigo.


	

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