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

[David Rientjes]

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