Re: FUSYN and RT

[Inaky Perez-Gonzalez <inaky@linux.intel.com>]

>>>>> Steven Rostedt <rostedt@goodmis.org> writes:

> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> >>>>> Steven Rostedt <rostedt@goodmis.org> writes:
>> 
>> I see--would the following fit your view?
>> 

> I think it's time that I take a look at the fusyn code. I don't have
> all the emails on this thread, could you point out to me where I can
> see the latest fusyn patch. Thanks.

http://developer.osdl.org/dev/robustmutexes/fusyn/20040510

There you have the a full patch against 2.6.10, against the previous
stable release (2.3.1) and the patch broken up in parts (the first one
001.msg has the index). 

You want 016.msg and 020.msg, the ones that implement fulocks (the
mutexes) and user space fulocks. 

013.msg has all the priority change engine (along with the queues);
__fuqueue_waiter_chprio() is the function.

In the same page site, up a couple of levels, three is info on how to
grab it from CVS. There is also the OLS 2004 stuff which explains
things in detail.

> It's getting late where I am, and I'm getting tired, so I'm a little
> slow right now.  Is what you are showing me here what is currently
> in fusyn or a proposal with the merging of Ingo's rt_mutex?  Reason
> why I'm asking, is what's the difference between the owner here and
> in fuqueue's spin_lock?

This is all without taking into account Ingo's work (you could say it
is kind of parallel/redundant/etc). In any case, to sum up w/ what
Sven said, the spinlock would be a raw_spinlock_t when that makes it
into the kernel. It just protects access to the fuqueue/fulock/ufulock
structures. 

>> This has an in kernel API so you can use it from modules or kernel
>> code.
>> ...

> This above structure would represent the user space wrapper
> structure that I meant with the fusyn structure containing the
> rt_mutex lock.  Right?

Yep

> Also in the above, is the fuqueue_ops the ops we mentioned earlier
> as the links into PI?

Yes and no.

Yes because the ops are there to be able to be able to do the kind of
things that user space mutexes need done differently (look for the
fu*_op_* functions--or fulock_ops and ufulock_ops).

However, in the case of the PI handling--that is just priority change
handling--the op is the same for both fulocks and user space fulocks.

But the priority change handling is different for queues, so you need
an op to distinguish.

> Sorry about being totally ignorant here, but it's the end of the day
> for me, and I'm starting to feel burnt out.

That's when you do 'shutdown -h now' and go for a beer :)

-- 

Inaky

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