Re: [GIT pull] timer fixes for 3.4

[Thomas Gleixner]

On Thu, 12 Apr 2012, Linus Torvalds wrote:

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

Fair enough.

Though last time I tried to do that (IIRC, it was a sanity check on a
timespec) I was forced to go the deprecation way ....

Times are changing :)

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