Steven A. Falco wrote:
> Your patch makes sense.
> I have some results, but I'm not sure I understand what they mean. I've
> attached the test program that I am using. Here is what it outputs:
> bash-3.00# ./o2
> Trying to free nonexistent resource <0000000000000000-00000000c0000001>
> get leds: -16 Device or resource busy
> put leds: 0 Success
> Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
> get low_mem: -16 Device or resource busy
> put low_mem: 0 Success
Actually, we should define rt_misc_put_io_region() as a void routine,
since the kernel does not return any status from release_region(). At
this chance, I've fixed this, since returning 0 albeit a failure message
is dumped to the kernel log upon error is disturbing.
> I am a little unclear on request_resource() - the return code is
> backwards of what I would have expected. Looking at examples in the
> kernel, it appears that request_resource() returns EBUSY when things go
> well, and it returns 0 when things go badly. Like I said, that seems
> backwards, but I guess it makes sense - EBUSY apparently means that the
> resource is _now_ busy?
request_resource() should return a valid resource descriptor address
upon success, which Xenomai converts to zero. Conversely, -EBUSY is
returned if request_region() sends us back a NULL value, since this is
how check_region() behaves.
> Anyway, following the kernel examples, my program considers a non-zero
> return as success. At that point I release the region. If instead, I
> get a zero return, then I treat that as a failure, and don't release the
> The part I don't understand is why I get the "Trying to free nonexistent
> resource" messages. Since I am getting an EBUSY, I thought that meant I
> owned the resource, and that I should release it...
I suspect request_region() did actually fail.
> Also, the addresses printed above are a bit strange. For example, I
> would have thought that instead of
> "<0000000000000000-00000000c0000001>", it would print
> "<00000001c0000000-00000001c0000013>". Perhaps that is a clue - maybe
> the start and length are not being passed correctly.
> One more question. It appears that if my program crashes, that the
> region will never be released. So, the normal behavior of an exiting
> process freeing all its resources doesn't seem to be guaranteed.
As a matter of fact, we track all common objects like sema4s, mutexes,
queues, and so on, but not I/O regions. Consider this as an illustration
of our absolute laziness, since we do have the proper infrastructure to
handle I/O regions in the auto-cleanup process too.
> Philippe Gerum wrote:
>> Philippe Gerum wrote:
>>> Steven A. Falco wrote:
>>>> The rt_misc_get_io_region() has the "start" argument as an unsigned
>>>> long. On the PPC440, we have a 36-bit address space, where the I/O
>>>> registers are generally above the 4GB area. For example, the UART is at
>>>> address 0x1ef600300.
>>>> The Linux request_region call has "start" typed as a resource_size_t,
>>>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even
>>>> though this is a 23-bit processor).
>>>> Is this something that should be handled by xeno-config? It could
>>>> append a CFLAG indicating the size of a resource.
>>> Or use a 64bit long unconditionally, to keep the same kernel-based
>>> implementation, since there is no performance issue for this call. In
>>> any case, we need to fix the API before 2.4 final is out -- which will
>>> also affect the ABI, but it already changed during the 2.4 development
>>> phase anyway.
>> Does this patch work for you?
Xenomai-core mailing list