Herrera-Bendezu, Luis wrote:
>> I think we can change rtdm_iomap_to_user to take src_addr as
>> and propagate this internally properly. We also need to add a wrapper
>> for phys_addr_t for kernels that doesn't support this (<2.6.28). To my
>> current understanding, this should be sufficient, right?
> This is a diff against Xenomai version 2.4.8 and Linux version 2.6.28 to
> handle RTDM mapping to user space of devices located at addresses > 4
Does it apply against git-head as well? Note that this won't make it
into stable 2.4.
> Rather than modifying existing rtdm_iomap_to_user() API a new one is
> added, rtdm_iomap_to_user64() (to mimic mmap64()). Since this is a user
> API it can not use phys_addr_t so unsigned long long is used for the
64 bit is not related to phys_addr_t. It /may/ be 64 bit, but it may
also be less (or more one day...?). So let's switch the existing
interface, just like the kernel does.
And it is not a user API; it is used between the driver and RTDM only.
How the driver deals with this in its user interface is a different
story. I think there is currently no publicly available driver that maps
I/O space into a user application, thus there is probably no stable RTDM
profile that uses unsigned long to specify a physical address.
> I tried to use rtdm_iomap_to_user() on a kernel module initialization
> section of my RTDM driver and passing NULL to user_info argument. This
> causes an invalid memory access and system panic. How can this
> function be called from kernel intialization code?
Not at all. It is supposed to be called on behalf of a user application,
asking the driver to map some area into its address space. Then you have
a valid user_info at hand.
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list