"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
