[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50BD4680.7090103@akamai.com>
Date: Mon, 03 Dec 2012 18:40:32 -0600
From: Josh Hunt <johunt@...mai.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: "jaxboe@...ionio.com" <jaxboe@...ionio.com>,
"kay.sievers@...y.org" <kay.sievers@...y.org>,
"tj@...nel.org" <tj@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH] block: Restore /proc/partitions to not display non-partitionable
removable devices
On 12/03/2012 06:06 PM, Andrew Morton wrote:
> On Mon, 19 Nov 2012 18:56:49 -0800
> Josh Hunt <johunt@...mai.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.
Thanks for looking at this.
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists