Re: [GIT pull] timer fixes for 3.4

From: Linus Torvalds
Date: Thu Apr 12 2012 - 18:46:53 EST


On Thu, Apr 12, 2012 at 3:39 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>>
>> That said, would people actually *report* those messages?
>>
>> In general, for things like this, it's probably better to just make
>> the change (especially if you have several distros you can test), and
>> then add a printk_once() for the case that changed. Then, if people
>
> I changed it to a printk_once() already.

No, I meant that the whole message should probably have been added
when actually changing the semantics.

If you have good reason to believe that some ABI change (a) does not
actually have any reason to break anything and (b) worth doing, then I
think it should just have been done (but during the merge window only,
of course).

And if (a) or (b) aren't true, then we're not going to change the ABI
at all, so the whole point is moot.

The printk_once (or, for that case WARN_ON_ONCE() may even be
worthwhile) would then just be a "oops, we were wrong" kind of
message, and would just mean that the commit would be reverted.

I think the whole "let's deprecate this six months into the future" is
unnecessary. Yes, it may well be worth doing for something with bigger
consequences, but I think that for something like this, it's just
overthinking the issue.

If it really is something we want to fix, I think it's much better to
just say "let's fix it, and if somebody notices, we'll have to go
back". The printk_once or WARN_ON is then just a polite way to avoid
having people have to bisect to it etc if it's subtle (and then we
would plan to remove *that* later).

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