Dmitry Adamushko wrote:
>> > + if (!err && name) {
>> > + xnpnode_t *pnode = &__intr_pnode;
>> >
>> > - if (!err)
>> > - err =
>> > - xnregistry_enter(intr->name, intr, &intr->handle,
>> > - &__intr_pnode);
>> > + if (!*name) {
>> > + /* Since this is an anonymous object (empty
>> name on entry)
>>
>> Isn't a NULL name representing an anonymous object as well?
>
> Anonymous objects are supported only for user-space clients.
> We agreed on it with Philippe when similar code was introduced for
> other objects. In this case, name is not NULL but "\0" on entry of
> native::rt_object_create (object = mutex,event,etc.).OK, I see. > > Now, don't ask me why the same is not applicable for the kernel-side > objects as I'll have to think about it (can't recall right now) and > may overheat. Likely, just some political issues. Yes, we want to make > life of kernel-side developers a bit more difficult. Namely, want an > object to be exported via registry? Give a valid name upon its > creation. > >> > - xnintr_init(&intr->intr_base, name, irq, isr, iack, mode); >> > xnobject_copy_name(intr->name, name); >> > + xnintr_init(&intr->intr_base, intr->name, irq, isr, iack, mode); >> >> This will set xnintr_t::name to "" if name is NULL - intentionally? > > xnintr_t::name becomes a reference to RT_INTR::name. The later one > exists as long as the former anyway so there shoudn't be a broken > reference. Yes, this specifically addresses Mathias' concern about passed names that are temporary variables. It just leaves xnintr_t::name with an emptry string instead of "unknown" in some cases. Either xnintr_init needs to take care of this, or we should catch that case already here. I think empty strings in /proc/xenomai/irq are bad in case of shared IRQ lists. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
