From: Boaz Harrosh <openosd@gmail.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [RFD] brd.ko Never supported partitions should we remove the dead code ?
Date: Tue, 29 Jul 2014 20:13:47 +0300 [thread overview]
Message-ID: <53D7D64B.5080504@gmail.com> (raw)
In-Reply-To: <20140729165603.GN6754@linux.intel.com>
On 07/29/2014 07:56 PM, Matthew Wilcox wrote:
> On Tue, Jul 29, 2014 at 07:37:49PM +0300, Boaz Harrosh wrote:
>> But before we are running to fix this bug. Could we please do better and just remove the support for partitions
>> all together.
>> Since it *never* worked anyway, so probably no one needs it! Surly no one used it
>
> I fixed this in patch 4/22 of the v8 series. The correct place to
> handle partitioning is in the block layer, not the individual drivers
> (nor the filesystems).
>
Sir Mathew hi
> @@ -378,10 +378,12 @@ static int brd_direct_access(struct block_device *bdev, sector_t sector,
>
> if (!brd)
> return -ENODEV;
> + sector += get_start_sect(bdev);
> if (sector & (PAGE_SECTORS-1))
> return -EINVAL;
> +/* Check is wrong here we need to check against bdev->bd_part->nr_sects */
> if (sector + PAGE_SECTORS > get_capacity(bdev->bd_disk))
> return -ERANGE;
> page = brd_insert_page(brd, sector);
> if (!page)
> return -ENOSPC;
you mean you fixed the brd_direct_access() hunk by pointing all users to a wrapper
that does the proper offsetting, sure.
But that is not the main bug I was talking about, the main BUG is that partitions are
not supported at all because of the clubber of *part in brd_probe()
> @@ -558,7 +564,8 @@ static struct kobject *brd_probe(dev_t dev, int *part, void *data)
> kobj = brd ? get_disk(brd->brd_disk) : NULL;
> mutex_unlock(&brd_devices_mutex);
>
> - *part = 0;
> +// Fix the partition BUG *part comes in correctly must not need to touch it
> +// *part = 0;
> return kobj;
> }
And my point is that: No one uses partitions with brd, why should we not remove it
all together, why fix it and keep it?
Cheers
Boaz
next prev parent reply other threads:[~2014-07-29 17:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 16:37 [RFD] brd.ko Never supported partitions should we remove the dead code ? Boaz Harrosh
2014-07-29 16:56 ` Matthew Wilcox
2014-07-29 17:13 ` Boaz Harrosh [this message]
2014-07-29 17:19 ` Ross Zwisler
2014-07-30 11:11 ` Boaz Harrosh
2014-07-30 14:15 ` [PATCH 1/2] brd: Fix the partitions BUG Boaz Harrosh
2014-07-30 14:18 ` [PATCH 2/2] brd: Fix brd_direct_access with partitions Boaz Harrosh
2014-07-30 15:34 ` Matthew Wilcox
2014-07-30 15:37 ` Boaz Harrosh
2014-07-30 16:50 ` [PATCH 1/2] brd: Fix the partitions BUG Ross Zwisler
2014-07-30 18:37 ` Boaz Harrosh
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=53D7D64B.5080504@gmail.com \
--to=openosd@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-scsi@vger.kernel.org \
--cc=ross.zwisler@linux.intel.com \
--cc=willy@linux.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 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.