Messages in this thread |  | | Date | Fri, 13 Apr 2012 01:01:46 +0200 (CEST) | | From | Thomas Gleixner <> | | Subject | Re: [GIT pull] timer fixes for 3.4 |
| |
On Thu, 12 Apr 2012, Linus Torvalds wrote:
> 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).
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
|  |