Philippe Gerum wrote:
maybe we should go as far as formalizing the "stringification" of a
Dmitry Adamushko wrote:
As you noticed below, the point is that this feature should be
kernel-based code only; for user-space, we're toast: typical
problem since we need the registry to cross the space boundaries but
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
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
Ok, I'd probably vote for the 2-nd approach.
Definitely better since this keeps the semantics consistent across
as a URL:
it still feels a teeny bit hacky, but the url prefix at least makes its
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
be globally visible, and its not clear to me which they are. Anyway,
/proc/ipipe/* file is a clumsy way to get addresses of xeno-objects to