Dmitry Adamushko wrote:
Philippe Gerum <[EMAIL PROTECTED]> wrote on 10.10.2005 13:09:13:

 > Dmitry Adamushko wrote:
 > > Philippe Gerum <[EMAIL PROTECTED]> wrote on 05.10.2005 14:13:07:
 > >
 > >  >
 > >  > Your patch is ok, my implementation was uselessly convoluted.
 > >
 > > Ok, then it's enclosed.
 > >
 > > 2005-10-05  Dmitry Adamushko  <[EMAIL PROTECTED]>
 > Applied, thanks.
 > ...


It looks like something wrong with the xenomai mailing list. I have got your answer but only one copy (you specified my own e-mail) and I haven't got my own message on the list (but I've cc'ed "xenomai-core").

Your mail to the list was blocked since you used an unregistered address to send it (

One more thing. I had a discussion with Steven Seeger regarding the use of NULL-named objects from the user space. I cc'ed you but probably you were too buzy at that time. The problem is that one may create successfully a NULL-named object but then there is no way to use it since all further calls give an error (some funny stuff there indeed :)

So a simple fix would look like:

for all rt_OBJECT_create() calls in libnative:

int rt_mutex_create(RT_MUTEX *mutex, const char *name)

+ if (!name)
+ return -E_SOMETHING; // E_INVAL?

return XENOMAI_SKINCALL2(__xeno_muxid,

What do you think? Or are there any reasons to keep it as is now?

The reason is to allow anonymous objects to be created, so that the descriptor could only be shared by tasks belonging to the same address space if they happen to all have access to the descriptor's memory. Kind of semi-private object if you want. The fact that such an object is non-bindable should not make it unusable actually.

p.s. I have cc'ed "" for both reasons to test the mailing list and, well, maybe someone else has an opinion on the matter.

 > --
 > Philippe.

Best regards,



Reply via email to