Philippe Gerum wrote:
> Steven A. Falco wrote:
>> Solved.  As you pointed out, Xenomai inverts the returned value from
>> request_region.  So, that was a bug in my application.
>>
>> However, turns out that instead of request_region, I have to use
>> request_mem_region.  This is because the I/O region only goes up to
>> 2^32, but the mem region goes up to 2^64.
>>
>> So, attached is a patch to add two new syscalls: rt_misc_get_mem_region
>> and rt_misc_put_mem_region.
>>
> 
> Thanks. At this chance, I've reworked the I/O region support to
> introduce descriptors, so that this API conforms to the
> one-descriptor-per-object rule commonly followed by other services from
> the native skin. I've merged your MMIO support on top of this. The added
> bonus is that auto-cleanup upon process exit becomes available with I/O
> regions too, since we now have the proper descriptor to hold the cleanup
> data.
> 
> The calls supporting this scheme are named rt_io_get_region, and
> rt_io_put_region, taking a RT_IOREGION object descriptor to hold the
> internal resource information. The rt_misc_io_get/put_region API is now
> deprecated starting with 2.4-rc6, albeit still available to allow for
> smooth transition; one will only get a warning as a reminder to upgrade
> to the new calls when using the old ones. e.g.
> 
> RT_IOREGION iorn;
> 
> rt_io_get_region(&iorn, label, start, len, IORN_IOPORT)
> is equivalent to calling:
> rt_misc_get_io_region(start, len, label)
> 
> the same way,
> 
> rt_io_get_region(&iorn, label, start, len, IORN_MEMORY)

s,IORN_MEMORY,IORN_IOMEM,

(for consistency reason with Linux's naming scheme)

> is equivalent to calling:
> rt_misc_get_mem_region(start, len, label)
> 
> Conversely,
> 
> rt_io_put_region(&iorn)
> is equivalent to calling:
> rt_misc_put_io/mem_region(start, len)
> 
> 


-- 
Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to