[Xenomai-help] mmap and secondary mode

[Xenomai-help] mmap and secondary mode

[Roderik_Wildenburg]

Just to be sure :
Does the access of a mmaped address (real_mmamp of a device file e.g.
/dev/dualportmemory) force Xenomai to switch to secondary mode ?
I would say yes, as the access of the address probably results into a
read/write of the device file.
Am I right ?

Thanks for your help
Roderik

Re: [Xenomai-help] mmap and secondary mode

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Roderik_Wildenburg@domain.hid wrote:
> Just to be sure :
> Does the access of a mmaped address (real_mmamp of a device file e.g.
> /dev/dualportmemory) force Xenomai to switch to secondary mode ?
> I would say yes, as the access of the address probably results into a
> read/write of the device file.
> Am I right ?

Depends. If that mapping takes place directly on a physical memory
region *ahead-of-use*, then you are safe (like with rtdm_iomap_to_user
from 2.3-devel). But if there is some Linux driver logic in between that
is triggered via page faults on access to those memory blocks, this is
certainly indeterministic. Probably easy to find out by analysing the
Linux driver in question /wrt its mapping code.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] mmap and secondary mode

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Roderik_Wildenburg@domain.hid wrote:
>> Just to be sure :
>> Does the access of a mmaped address (real_mmamp of a device file e.g.
>> /dev/dualportmemory) force Xenomai to switch to secondary mode ?
>> I would say yes, as the access of the address probably results into a
>> read/write of the device file.
>> Am I right ?
> 
> Depends. If that mapping takes place directly on a physical memory
> region *ahead-of-use*, then you are safe (like with rtdm_iomap_to_user
> from 2.3-devel). But if there is some Linux driver logic in between that
> is triggered via page faults on access to those memory blocks, this is
> certainly indeterministic. Probably easy to find out by analysing the
> Linux driver in question /wrt its mapping code.

But it should be save to call the driver's mmap function in secondary 
mode (init code) and use the virtual address later on in primary mode.

Wolfgang.