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
>>> 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.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list