Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> File descriptors are all identically structured objects, so at worst you
>>>>>> ruin some other app's day. But the registry contains arbitrary objects
>>>>>> with different internal layout. If you start assuming object_a * is
>>>>>> object_b * and use the pointer etc. included in a as if they have the
>>>>>> meaning of b, you quickly ruin the kernel's day as well. Therefore,
>>>>>> native, e.g., does magic checks after fetching from the registry. As I
>>>>>> said, this test here works differently, but it has the same effect and
>>>>>> impact.
>>>>> By the way, would not it make sense to have separate hash tables for
>>>>> separate objects types ? I mean then we would not need any validation,
>>>>> and several object types could use the same name.
>>>> From that POV a good idea. The only issue I see is a management problem:
>>>> How many mutex, thread, queue, whatever slots do you want in your
>>>> system? One knob for them all? Or countless knobs for all object types
>>>> of all skins? That's hairy, I'm afraid.
>>> xnmalloc, the pool size is the limit.
>> You mean kind of "xnrealloc", including atomically copying potentially
>> large descriptor tables over? Sounds not that attractive.
> No, I mean the hash table contains pointers, and the objects are
> allocated dynamically...

Handle lookup is not going through hash tables. It's index based (like
file descriptors).


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to