Re: [RFC/PATCH] FUSYN Realtime & robust mutexes for Linux, v2.3.1

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxx> wrote:

> but, couldnt there be more sharing between futex.c and fusyn.c? In
> particular on the API side, why arent all these ops done as an
> extension to sys_futex()? That would keep the glibc part much simpler
> (and more compatible) as well. [...]

i believe the key to integration of this feature is to try to make it
used by normal (non-RT) apps as much as possible. I.e. try to make
current futexes a subset of fusyn.c and to merge the two APIs if
possible (essentially renaming your fusyn.c to futex.c and implementing
the futex API). Is this possible without noticeable performance overhead
(and without too many special-cases)?

such an approach would ensure that key portions of the code would be
triggered by everyday apps. Developers wouldnt break the feature every
other day, etc. Deadlock detection and priority boosting might not be
tested this way, but the basic locking/waking/VM-keying mechanism sure
could be.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/