From: Alexey Dobriyan <adobriyan@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: xiaoming.wang@intel.com,
Linux Kernel <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] proc: move the adding option Ngid to the end of proc/PID/status
Date: Thu, 23 Apr 2015 23:32:26 +0300 [thread overview]
Message-ID: <20150423203226.GA1765@p183.telecom.by> (raw)
In-Reply-To: <20150421151119.GB9455@htj.duckdns.org>
On Tue, Apr 21, 2015 at 11:11:19AM -0400, Tejun Heo wrote:
> On Tue, Apr 21, 2015 at 05:00:07PM +0300, Alexey Dobriyan wrote:
> > > The only reason for changing the position is because
> > > there's this specific breakage. The goal should be working around
> > > that specific case while keeping the impact minimum on everyone else.
> >
> > If there are TWO incorrect parsers, one for TracerPid, another for Ngid,
> > you CAN'T workaround it. And if you can't workaround you choose code
> > which was written first, namely, TracerPid one.
>
> Not when the code has been out for 1.5 years. Minimizing the
> disturbance is the better course of action. Look at the file. If you
> move ngid to the end now, it's gonna shift most of the file content,
> which is what caused the problem in the first place.
>
> We don't know what's out there which again was the same problem which
> triggered this thread in the first place. Why would you take the same
> amount of risk when you can fix the known issue with less amount of
> changes?
There are 2 fields before Ngid and 35+ after Ngid. So the risk is not
the same. Potentionally, Ngid addition broke almost every parser.
> Just put ngid after tracerpid. That way, we can fix the
> known problems while changing the offsets of only four fields. At
> this point, no change to the file layout is "right". Such thing isn't
> defined regardless of who came first. The only thing we can do is
> working around the known cases while minimizing possible impacts.
We'll return to this thread when next breakage will be reported,
I promise. :^)
next prev parent reply other threads:[~2015-04-23 20:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 13:23 [PATCH] proc: move the adding option Ngid to the end of proc/PID/status Alexey Dobriyan
2015-04-17 14:26 ` Tejun Heo
2015-04-17 15:05 ` Alexey Dobriyan
2015-04-17 15:12 ` Tejun Heo
2015-04-21 8:19 ` Wang, Xiaoming
2015-04-21 14:00 ` Alexey Dobriyan
2015-04-21 15:11 ` Tejun Heo
2015-04-23 20:32 ` Alexey Dobriyan [this message]
2015-04-24 15:50 ` Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2015-04-17 2:13 Wang Xiaoming
2015-04-17 2:56 ` Tejun Heo
2015-04-17 3:15 ` Wang, Xiaoming
2015-04-17 3:26 ` Tejun Heo
2015-04-17 3:37 ` Wang, Xiaoming
2015-04-17 3:42 ` Tejun Heo
2015-04-17 5:36 ` Wang, Xiaoming
2015-04-21 15:19 ` Eric W. Biederman
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=20150423203226.GA1765@p183.telecom.by \
--to=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=tj@kernel.org \
--cc=xiaoming.wang@intel.com \
/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