* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > Thomas' changes are more obviously purpose driven, and Daniel's
> > appear more like just cleanups. So given that, if it were me, I'd
> > put Thomas changes in first, and re-diff Daniel's non-redundant
> > changes on top.
>
> Seems backwards , clean ups should always go first. If Thomas had
> started off my patch set his changes would have been smaller and
> hopefully stronger. [...]
if it were the same area of code, and if all your cleanups were fine,
i'd agree. But even assuming that all your cleanups are fine, this is
90% /not/ the same area of code. Thomas's changes refactor the
clockevents infrastructure, while passingly touching clocksources too,
on an as-needed basis. Your changes touch the clocksource area of code.
In that sense Thomas' changes are more important and you should be able
to refactor your queue ontop of Thomas' (trivial) change to the
clocksources code.
You are complaining that we didnt pick up your high-flux cleanups, but
we pointed out our reasons. In fact we couldnt really even consider your
queue because the last version of yours when we did ours was 2 months
old and yours included the showstopper sched_clock() changes. Your queue
had all the signs of abandonment, so your injection into this submission
of the -hrt queue to suggest that your queue is suddenly a 'must have'
is quite puzzling to me.
Ingo
-
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/
