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

[Perez-Gonzalez, Inaky]

> From: Ingo Molnar [mailto:mingo@xxxxxxx]
> 
> * Perez-Gonzalez, Inaky <inaky.perez-gonzalez@xxxxxxxxx> wrote:
> 
> > Fusyn aims to provide primitives to solve a bunch of gaps in POSIX
> > compliance related to mutexes, conditional variables and semaphores,
> > POSIX Advanced real-time support as well as adding mutex robustness
> > (to dying owners) and deep deadlock checking.
> 
> the sched.c bits look clean enough.

The bit that scares me is the hook into effective_prio() in the
scheduler fast-path for the prio boost. It is a minimal op, but I know
how cautious are you guys on poking there.

> 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's what I did initially and many people barked at me because it made
sys_futex even uglier. Somebody [I can't remember the thread and I cannot
find it] said that sys_futex() should have been split in a number of syscalls
from the beginning, not multiplexing--and that they should do that in 2.7
to ease up a transition.

As well, I need to take different arguments [flags for the fulocks, for example].
For the sys_ufuqueue_*(), it makes sense to do a redirection for simplification,
emulating the sys_futex() thingies, but for fulocks, they are completely 
different beasts. It makes little sense, it is a locking interface, not a 
waitqueue interface. 

> That would keep the glibc part much simpler (and more
> compatible) as well. You'd still get all the glory of implementing true

I'll work on the sys_futex() redirection to ufuqueues during today [let's
see if I can get something done before taking off on vacation] and as soon
as I come back, but for the ufulocks...the interface is too different. I
think it makes more sense to clean up the glibc implementation, make a truly
layered set of calls redirecting the lll_ stuff at compile time [and run
time where needed/desired] that would allow the user to select what he wants
to do (when in the know) and default to the best combination for the general
public.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
-
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/