Re: [Xenomai-core] rtdm_iomap_to_user with phys addr > 4G

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

Herrera-Bendezu, Luis wrote:
> Jan,
> 
>> I think we can change rtdm_iomap_to_user to take src_addr as 
>> phys_addr_t
>> 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
> GB.

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
> interface.

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux