Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 12 Apr 2012 15:46:34 -0700 | Subject | Re: [GIT pull] timer fixes for 3.4 |
| |
On Thu, Apr 12, 2012 at 3:39 PM, Thomas Gleixner <tglx@linutronix.de> 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
| |