Re: patch] Real-Time Preemption, plist fixes

[Daniel Walker <dwalker@mvista.com>]

On Sun, 5 Jun 2005, Thomas Gleixner wrote:

> The patch fixes a couple of really annoying issues in the PI code of the
> Real-Time-Preemption patch

You mean really annoying in the plist code?
 
> 1. Fix the insertion order according to the specified intentions
> 
> The desired action was inserting in descending priority and FIFO mode
> for matching priority. The resulting action of the code was inserting in
> descending priority and inverse FIFO mode for matching priority. 

This is good.
 
> 2. Add the proper list_head initializer in the replacement path.

Not sure what you mean here.
 
> 3. Remove the bogus checks in the delete function for 
>  A. !list_empty(&pl->sp_node)
>  B. else if (pl->prio == pl_new->prio)
> 
> Those checks just covered the dumbest implementation detail of plist at
> all. See 4.)
> 
> 4. Make plist_entry() work as expected by anybody who ever used
> list_entry(). Add a plist_first_entry macro for those places where the
> provided functionality was accidentaly correct.
> 
> Application example:
> 
> plist_for_each_safe(curr1, next1, &old_owner->pi_waiters) {
> 	w = plist_entry(curr1, struct rt_mutex_waiter, pi_list);
> 	.....
> }
> 
> A moderate experienced Linux programmer would expect, that
> plist_entry(curr1,...) returns the first entry of the list
> &old_owner->pi_waiters. Looking into the plist_entry macro after
> spending hours of witchcrafting reviels that the result is the next
> entry of the first entry of the list.
> 
> #define plist_entry(ptr, type, member) \
> 	container_of(plist_first(ptr), type, member)
> 
> No further comment necessary.

I already released a patch to fix this.
 
> 5. Modify the comments in the header file to explain the real intention
> of the implemenation.
> 
> Changing fundamental implemtation details and keeping the original
> comments is just provoking false assumptions. I apologize hereby for all
> maledictions I addressed to the original author.

You should wait till it's stable before you finalize the documentation.

> + * (C) 2005 Thomas Gleixner <tglx@linutronix.de>
> + * Tested and made it functional. I'm still pondering if it is
> + * worth the trouble.
> + *

Gimme a break Thomas..

Daniel

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