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

[Perez-Gonzalez, Inaky]

>From: 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.

Errr....shut, that was my or your email program screwing
things up...that =20, I mean, that's MIME for line break.

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

The -1/0/+1 sounds pretty good. 

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

I guess I am still very biased by my implementation, where returning
that was almost free because of how the functions where implemented
(which steamed from the fact that they had to always compute the
new priority to store it in the head).

So as you say, the best way is wrapping your primitives around. I'd
suggest a shorter postfix, something like _prio() or _chkprio().

Thanks,

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