Re: [PATCH 2/4] rt_mutex: add new plist implementation

[Oleg Nesterov]

"Perez-Gonzalez, Inaky" wrote:
>
> >From: Oleg Nesterov
>
> >+extern void plist_add(struct pl_node *node, struct pl_head *head);
> >+extern void plist_del(struct pl_node *node);
>
> At least I'd add return codes for this if the head's priority=20
> changes (or in this case, because head's have no prio, if the=20
> first node's  prio change).

I am not sure I understand you. Why should we track ->prio=20 changes?
plist should be generic, I think.

Original code:
	unsigned plist_add (struct plist *pl, struct plist *plist)
	{
		__plist_add_sorted (plist, pl);
		if (pl->prio < plist->prio) {
			plist->prio = pl->prio;
			return !0;
		}
		return 0;
	}

This could be:
	int plist_add_and_check_min_prio_changed(node, head)
	{
		plist_add(node, head);
		return plist_next(head) == node;
	}

Or plist_add() could be easily changed to return -1,0,+1 to indicate
min/max prio changed/unchanged.

But may be it is better to return 'iter' from plist_add(). This way
we can avoid scanning ->prio_list when we add the node with the same
->prio next time. I am not sure.

And please note that pl_head "has" prio:

	plist_empty(head) ? INT_MAX			// -1 ?
			  : plist_next(head)->prio

> Both function's  logic should make it easy to test and it'd save
> a lot of code in the caller.

Currently these functions are used in void context only. I think
it is better to add return codes when callers need them.

What do you think?

Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/