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.
> ...
btw,
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 (datacon.at).
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,
__xeno_mutex_create,
mutex,
name);
}
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 "xenomai-core@gna.org" for both reasons to test the
mailing list and, well, maybe someone else has an opinion on the matter.
> --
>
> Philippe.
---
Best regards,
Dmitry
--
Philippe.
