All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Krol <hawk@pld-linux.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <npiggin@suse.de>,
	linux-fsdevel@vger.kernel.org, stable@kernel.org
Subject: Re: [patch] brd: fix ramdisk regression
Date: Tue, 20 May 2008 22:24:01 +0200	[thread overview]
Message-ID: <48333361.7050408@pld-linux.org> (raw)
In-Reply-To: <20080520120439.0fed8f94.akpm@linux-foundation.org>

>> --- linux-2.6.25/drivers/block/brd.c.orig	2008-04-17 04:49:44.000000000 +0200
>> +++ linux-2.6.25/drivers/block/brd.c	2008-05-18 01:18:28.381903343 +0200
>> @@ -442,6 +442,7 @@
>>  	disk->fops		= &brd_fops;
>>  	disk->private_data	= brd;
>>  	disk->queue		= brd->brd_queue;
>> +	disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
>>  	sprintf(disk->disk_name, "ram%d", i);
>>  	set_capacity(disk, rd_size * 2);
>>  
> 
> Why is it a "regression"?
> 
> The change in 2.6.25 was a back-compatible one.
> 
> This change is not a back-compatible one and if we're going to now
> withdraw the newly-added 2.6.25 feature then we should also withdraw it
> from 2.6.26.x and 2.6.25.x (if that is still under maintenance).  To
> reduce the incidence of "hey where did my feature go" problems.
> 
> Really, life would be simpler if we just left the accidentally-added
> feature in place.  What problems does it cause?

All kernels prior to 2.6.25 weren't displaying ramdisks in 
/proc/partitions. Since there are many userspace tools using infromation 
from /proc/partitions some of them may now behave incorrectly (I didn't 
tested any though). For example before 2.6.25 /proc/partitions was empty 
if no block devices like hard disks and such were detected by kernel. 
Now all 16 ramdisks are always visible there. Some software may rely on 
such information (I mean, on empty /proc/partitions).

There was quite similar situation back in 2004, and ramdisks were 
excluded back from displaying. Thats why I called this a regression 
(maybe a bit unfortunate). See this patch for info: 
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch

I also think that someone somewhere (long time ago) excluded ramdisks 
from /proc/partitions for good reasons. It is possible that now such new 
"feature" is harmless, but I think there are more chances that someone 
will say "hey, /proc/partitions has changed, now my software doesn't 
work" then "hey where did my new 2.6.25 feature go". nbd devices are 
also excluded, maybe for very same (unknown to me) reasons.

For me this change isn't problematic. Yes, it did broken my software and 
yes, I could fix my software but since its working only on specific 
kernels (precompiled by me) I've chosen to revert kernel change instead 
to get old behaviour.

Marcin

  reply	other threads:[~2008-05-20 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 13:41 [patch] brd: fix ramdisk regression Nick Piggin
2008-05-20 19:04 ` Andrew Morton
2008-05-20 20:24   ` Marcin Krol [this message]
2008-05-20 20:34     ` Andrew Morton
2008-05-20 21:32       ` [stable] " Chris Wright

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=48333361.7050408@pld-linux.org \
    --to=hawk@pld-linux.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.