Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range

David Rientjes
2010-10-18T22:00:47Z

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.