lkml.org 
[lkml]   [2005]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: FUSYN and RT
From
Date
On Wed, 2005-04-13 at 10:33 -0700, Daniel Walker wrote:
> On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
> > How hard would it be to use the RT mutex PI for the priority inheritance
> > for fusyn? I only work with the RT mutex now and haven't looked at the
> > fusyn. Maybe Ingo can make a separate PI system with its own API that
> > both the fusyn and RT mutex can use. This way the fusyn locks can still
> > be separate from the RT mutex locks but still work together.
> >
> > Basically can the fusyn work with the rt_mutex_waiter? That's what I
> > would pull into its own subsystem. Have another structure that would
> > reside in both the fusyn and RT mutex that would take over for the
> > current rt_mutex that is used in pi_setprio and task_blocks_on_lock in
> > rt.c. So if both locks used the same PI system, then this should all be
> > cleared up.
> >
> > If this doesn't makes sense, or just confusing, I'll explain more :-)
>
> I've thought about this as an option, but when I first started this
> thread It seemed like the two could work independently, and safely which
> doesn't appear to be the case any more.
>
> The problems with pulling out the PI in the RT mutex are that
> pi_setprio() does a walk over lock->owner and we're got two different
> lock structures now . I was thinking we could add something like
> lock_ops (get_owner(), wait_list_add(), wait_list_del(), ?? ) to
> rt_mutex_waiter, or abstract rt_lock. Then pi_setprio would just use the
> lock_ops instead of accessing a structure ..

Yeah, I was thinking of another structure within rt_mutex and what fusyn
uses. Like a pi_struct of some sort. And this would be the common
structure that holds the owner and prio or what ever that the pi_setprio
and friends need. This would probably be the easier approach, but for
the long run, I think I like your idea of the ops better.

-- Steve


-
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 20:54    [W:0.079 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site