That works perfectly.  Thanks!

   Steve


Philippe Gerum wrote:
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)




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

Reply via email to