linux-kernel - Re: [PATCH] mmc : general purpose partition support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 23 Sep 2011 12:56:54 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	Andrei Warkentin <awarkentin@...are.com>
Cc:	linux-kernel@...r.kernel.org, cjb@...top.org,
	linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc : general purpose partition support.

2011/9/23 Andrei Warkentin <awarkentin@...are.com>:
> Hi Namjae,
>
> I scanned over your changes to enable GP partitions, and while I
> did not yet test your changes, they do appear to be ok.
>
> Please CC me on the next version of your patch so I can give
> it a spin and Ack on it.
>
> I do suggest at least thinking about ways to improve on this. Back
> when I added boot partition support, I already didn't like the fact
> that the block driver had to be aware of the eMMC partitions, with all
> the code duplication and such. By adding four more partitions,
> you've compounded the problem and now you have six pieces of
> code that really look the same.
>
> The core/mmc.c right now scans the size values and stores them
> in mmc_card, and the block driver is smart enough to know what
> to do with them. Why not make the block code generic at the expense
> of keeping an array of structures in mmc_card? The block driver
> would then just iterate over these and create the additional devices. The partition
> switch routine would then operate on these structures, and could then be pulled out
> of the block driver, making it simpler.
>
> Each physical partition could be described by something like -
> struct mmc_part {
>    unsigned int size;
>    unsigned int cookie;        /* for mmc, idx used in mmc_switch, part_type from current mmc_blk_data */
>    char name[DISK_NAME_LEN];
>    bool force_ro;              /* to make boot parts RO by default */
> };
>
> Just an idea. Clearly, if MMC grows by another 4-5 possible partitions, it's not
> realistic to be copy-pasting the same block of code, nor would it make sense
> if/when these types of devices support an arbitrary amount of physical partitions.
>
> Thanks,
> A
>

Okay, I understand what you want. I will try to make patch included
your suggestion again.
Thanks for your review.
--
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/