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
