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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
