lkml.org 
[lkml]   [2005]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: FUSYN and RT
Date
From
>From: Daniel Walker [mailto:dwalker@mvista.com]
>
>On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
>
>> So no, you will not need the same API, at all :-) Fusyn manipulates
>> task->static_prio and only task->prio when no RT lock is taken. When
the
>> first RT-lock is taken/released it manipulates task->prio only. A
release
>> of a Fusyn will manipulate task->static_prio as well as task->prio.
>
>mutex_setprio() , I don't know if you could call that an API but that's
>what I was talking about.. They should both use that. I think it would
>be better if the RT mutex (and fusyn) didn't depend on a field in the
>task_struct to retain the old priority. That would make it easier ..
>
>This goes back to the assumption that the locking isn't intermingled
>once you get into the kernel . The RT mutex can safely save the owner
>priority with out a Fusyn jumping in and changing it and the other way
>around..

You should not need any of this if your user space mutexes are a
wrapper over the kernel space ones. The kernel handles everything
the same and there is no need to take care of any special cases or
variations [other than the ones imposed by the wrapping].

-- 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/

\
 
 \ /
  Last update: 2005-04-13 01:12    [W:0.124 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site