Messages in this thread | | | Date | Mon, 18 Oct 2010 15:00:36 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range |
| |
On Mon, 18 Oct 2010, H. Peter Anvin wrote:
> > It's not insane if there is no other way to ascertain that information. > > If it's available through sysfs or debugfs (and, even better, documented > > as part of the API in Documentation/ABI), then I don't think anyone would > > object to changing a log message. But I don't think all log messages > > should be fair game under some general principle if they are being changed > > (instead of just extending it) without a compelling reason, such as > > technically being incorrect in its present form. > > YES IT IS. In fact, it is completely and totally bananas bonkers. > > By not pushing for a proper maintainable ABI, you will have an > indefinite forward compatibility problem, and when predictably it > breaks, you'll complain. This is, however, backwards -- the right thing > would have been to say "I need this, this isn't available, I should add > a maintainable API and push it upstream", and perhaps add log parsing as > a backwards-compatibility solution. >
The problem is deciding what should be an ABI and what shouldn't an ABI when it isn't clear. It would be great if everything that is logged or shown to userspace would be part of an ABI and would be available no matter how much information is emitted to the log. That's not scalable, so we have to decide what userspace may depend on and design ABIs that provide that information in an extendable way that won't break or become obsoleted in the foreseeable future.
Since we can't do that for everything and we have no idea what users will find to parse from the dmesg, I'm advocating that if a change is proposed, like was in this case with ti->flags, and someone has a usecase where the information isn't available in any other way, that they speak up and come up with a maintainable solution so that we've identified the parties involved and can change that log message if necessary. I only think that should be done, though, when there is a compelling reason for the change.
I think that was done in this case by suggesting an alternative (printing, at minimum, "M" when a thread has TIF_MEMDIE set instead of the raw flag bits), but I don't think the change itself was compelling enough that it has to be done. That doesn't mean doing the change I suggested wasn't still appropriate, but at least it was known as a prerequisite before something like this should be merged.
| |