Messages in this thread | | | Date | Fri, 15 Apr 2005 21:05:06 -0700 | Subject | Re: FUSYN and RT | From | Inaky Perez-Gonzalez <> |
| |
>>>>> 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/
| |