From: "H. Peter Anvin" <hpa@zytor.com>
To: David Rientjes <rientjes@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/2] x86: Cleanup TIF value gaps in shift range
Date: Mon, 18 Oct 2010 14:43:57 -0700 [thread overview]
Message-ID: <4CBCBF9D.1060409@zytor.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1010181431440.15782@chino.kir.corp.google.com>
On 10/18/2010 02:36 PM, David Rientjes wrote:
> On Mon, 18 Oct 2010, H. Peter Anvin wrote:
>
>> The problem is that someone exports something as debugging information,
>> then someone else suddenly thinks it's an ABI. I believe the same
>> complainant in the past has objected to changing of formatting in dmesg,
>> which is equally insane.
>>
>
> 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.
-hpa
next prev parent reply other threads:[~2010-10-18 21:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-18 20:35 [PATCH 1/2] x86: Cleanup TIF value gaps in shift range Frederic Weisbecker
2010-10-18 20:35 ` [PATCH 2/2] x86: Remove stale TIF_DEBUG Frederic Weisbecker
2010-10-18 22:12 ` [PATCH v2] " Frederic Weisbecker
2010-10-18 20:47 ` [PATCH 1/2] x86: Cleanup TIF value gaps in shift range David Rientjes
2010-10-18 21:23 ` Thomas Gleixner
2010-10-18 21:28 ` H. Peter Anvin
2010-10-18 21:36 ` David Rientjes
2010-10-18 21:43 ` H. Peter Anvin [this message]
2010-10-18 22:00 ` David Rientjes
2010-10-18 23:23 ` H. Peter Anvin
2010-10-18 21:30 ` David Rientjes
2010-10-18 20:48 ` H. Peter Anvin
2010-10-18 21:10 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CBCBF9D.1060409@zytor.com \
--to=hpa@zytor.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox