On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote: > You basicly need 3 priorities: > 1) Actual: task->prio > 2) Base prio with no RT locks taken: task->static_prio > 3) Base prio with no Fusyn locks taken: task->?? > > 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.. Daniel - 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/
