From: Andrew Morton <akpm@linux-foundation.org>
To: Josh Hunt <johunt@akamai.com>
Cc: "jaxboe@fusionio.com" <jaxboe@fusionio.com>,
"kay.sievers@vrfy.org" <kay.sievers@vrfy.org>,
"tj@kernel.org" <tj@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] block: Restore /proc/partitions to not display non-partitionable removable devices
Date: Mon, 3 Dec 2012 16:54:36 -0800 [thread overview]
Message-ID: <20121203165436.0542933f.akpm@linux-foundation.org> (raw)
In-Reply-To: <50BD4680.7090103@akamai.com>
On Mon, 03 Dec 2012 18:40:32 -0600
Josh Hunt <johunt@akamai.com> wrote:
> On 12/03/2012 06:06 PM, Andrew Morton wrote:
> > On Mon, 19 Nov 2012 18:56:49 -0800
> > Josh Hunt <johunt@akamai.com> wrote:
> >
> >> We found with newer kernels we started seeing the cdrom device showing
> >> up in /proc/partitions, but it was not there before. Looking into this I found
> >> that commit d27769ec... block: add GENHD_FL_NO_PART_SCAN introduces this change
> >> in behavior. It's not clear to me from the commit's changelog if this change was
> >> intentional or not. This comment still remains:
> >> /* Don't show non-partitionable removeable devices or empty devices */
> >> so I've decided to send a patch to restore the behavior of not printing
> >> unpartitionable removable devices.
> >
> > d27769ec was merged in August 2011, so I after all this time, your fix
> > could be viewed as "changing existing behaviour".
> >
> > So perhaps it would be best to leave things alone. Is there any
> > particular problem with the post-Aug, 2011 behaviour?
> >
>
> We caught this by a script that parses /proc/partitions and made some
> assumptions about the contents therein. It had worked fine up until when
> this behavior changed. We were able to modify our script to get what we
> needed.
>
> The patch was meant to do two things: 1) understand if this was an
> unintended change and 2) if so, propose a solution to resolve it. Since
> the comment was left in the source I believe either a) my patch should
> be applied or b) a new patch with the comment removed should be put in
> since it's no longer correct. I did not think this type of change to
> kernel abi was generally acceptable.
>
> While the commit is over a year old, it changes behavior which had been
> in tact for a while (years?) from what I can tell. We were running 3.0
> with stable updates until we upgraded to 3.2 and hit this. Neither of
> these are what I would consider "old" kernels.
>
Yes, this is difficult. Removing existing entries is more likely to
cause damage than adding new ones, so I suspect the safest approach is
to just leave things as they now are.
In which case yes, we should repair that comment. ie: change it to a
comment which explains *why* we display removable devices. Unlike the
existing comment which tells us "what" but not "why", when "why" is
what we wanted to know, sigh.
prev parent reply other threads:[~2012-12-04 0:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 2:56 [PATCH] block: Restore /proc/partitions to not display non-partitionable removable devices Josh Hunt
2012-11-27 15:58 ` Josh Hunt
2012-12-04 0:06 ` Andrew Morton
2012-12-04 0:40 ` Josh Hunt
2012-12-04 0:54 ` Andrew Morton [this message]
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=20121203165436.0542933f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=jaxboe@fusionio.com \
--cc=johunt@akamai.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/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