Re: [Xenomai-core] Re: [syscall.c] rt_bind_queue/heap()

[Jim Cromie <jim.cromie@domain.hid>]

Philippe Gerum wrote:

> Dmitry Adamushko wrote:
>
>>> As you noticed below, the point is that this feature should be 
>>> active for
>>> kernel-based code only; for user-space, we're toast: typical 
>>> chicken-and-egg
>>> problem since we need the registry to cross the space boundaries but 
>>> the
>>> registry requires a name to index the object first. So yes, we need 
>>> to check for
>>> anonymous calls in every service taking a symbolic name in 
>>> native/syscalls.c,
>>> and return -EINVAL when applicable.
>>
>>
>>
>> I thought that "libnative" would be a better place since this way we
>> would avoid the user mode -> kernel mode switch.
>>
>>
>>> ...Or, we might auto-generate some dummy name in native/syscalls.c 
>>> we would pass
>>> to the registry when this situation arises, so that anonymous 
>>> creation and use
>>> from user-space would still be possible.
>>
>>
>>
>> Yep, in this case a name would be a string == object's address, thus
>> it's unique.
>>
>> Ok, I'd probably vote for the 2-nd approach.
>>
>
> Definitely better since this keeps the semantics consistent across 
> execution spaces.
>
maybe we should go as far as formalizing the "stringification" of a 
xenomai object
as a URL:
xeno_queue:0x45abc034
xeno_mutex:0xDEADBEEF
or
xeno:queue:0x0F00BAAB
xeno:mutex:
xeno:shared:TGID=100:0xdeadbeef

it still feels a teeny bit hacky, but the url prefix at least makes its 
use explicit.
In the last example, the url includes TGID=100, the idea being that it would
only be valid for user-space processes that were thread-group 100.

I dunno whether any such objects should get entries in /proc/ipipe/Xenomai*
On one hand, it would seem a decent rendevous point, but not all objects 
should
be globally visible, and its not clear to me which they are.  Anyway, 
reading a
/proc/ipipe/* file is a clumsy way to get addresses of xeno-objects to 
bind to.

thx
jimc