public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Caizhiyong <caizhiyong@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Karel Zak <kzak@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Wanglin (Albert)" <albert.wanglin@huawei.com>,
	Quyaxin <quyaxin@huawei.com>
Subject: Re: [PATCH] block: support embedded device command line partition
Date: Fri, 16 Aug 2013 10:02:39 -0600	[thread overview]
Message-ID: <520E4D1F.3000509@wwwdotorg.org> (raw)
In-Reply-To: <C3050A4DBA34F345975765E43127F10F1C0643F8@szxeml512-mbx.china.huawei.com>

On 08/15/2013 08:54 PM, Caizhiyong wrote:
>>> +blkdevparts=<blkdev-def>[;<blkdev-def>]
>>> +  <blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
>>> +    <partdef> := <size>[@<offset>](part-name)
>>> +
>>> +<blkdev-id>
>>> +    block device disk name, embedded device used fixed block device,
>>> +    it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
>>
>> The device-name isn't always fixed.
>>
>> For example, what if there are multiple SDHCI controllers, one hosting a
>> fixed eMMC device and the other an SD card? It's quite typical for the
>> eMMC's device name (which is likely what should be affected by this
>> feature) to be mmcblk0 when no SD card is present, yet be mmcblk1 when
>> an SD card is present. Is there a more precise/stable way to define
>> which device the command-line option applies to?
>   
> Yes. Fixed is for single controller.
> For multiple controllers, currently, there is not a simple way.
> I tend to do something in the eMMC driver, such as initialize order,
> but I have not tried.

There have been proposals before to try and create a fixed naming for
the controllers (or rather the block devices they generate...) but
they've been rejected. I don't think we should rely on being able to do
that.

>>> +
>>> +<offset>
>>> +    partition start address, in bytes.
>>> +
>>> +(part-name)
>>> +    partition name, kernel send uevent with "PARTNAME". application can create
>>> +    a link to block device partition with the name "PARTNAME".
>>> +    user space application can access partition by partition name.
>>
>> Do partitions usually have a PARTNAME attribute when probed through
>> normal mechanisms like MBR? If so, I guess this is fine.
>>
>> Perhaps we can just use , as the delimiter for all fields, rather than
>> special-casing part-name to use (), so:
>>
>> size,offset,partname,size,offset,partname,...
>>
>> The partname field could easily be empty if not needed.
> 
> If no need partname, your bootargs are mmcblk0:1G,1G,1G,...

Well, you always need the offset too. I don't think there's any harm in
forcing all fields to be specified in all cases; it makes the whole
system much more regular and less error-prone.

Alternatively, use a different separator between fields for a given
partition, and between partitions, e.g.:

size,offset,partname;size,offset,partname

That way, you know that if you see a ; you're looking at a new
partition, and hence the partname field need not always be specified.
Although, if you want to specify a partname but not an offset you'd
still need empty fields, so just requiring all fields to always be
present still seems safest to me.

  reply	other threads:[~2013-08-16 16:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-03  9:57 [PATCH] block: support embedded device command line partition Caizhiyong
2013-08-05 22:22 ` Andrew Morton
2013-08-06 10:53   ` Caizhiyong
2013-08-07  0:10     ` Andrew Morton
2013-08-13  6:02   ` [PATCH] block: add command line partition parser Caizhiyong
2013-08-14 22:57     ` Andrew Morton
2013-08-15  0:11       ` Brian Norris
2013-08-15  0:30         ` Andrew Morton
2013-08-15  3:38         ` Caizhiyong
2013-08-15  5:00           ` Brian Norris
2013-08-15  6:16             ` Caizhiyong
2013-08-15  7:09               ` Brian Norris
2013-08-15  7:45                 ` Caizhiyong
2013-08-15  8:32                   ` Brian Norris
2013-08-15 15:52 ` [PATCH] block: support embedded device command line partition Stephen Warren
2013-08-16  2:54   ` Caizhiyong
2013-08-16 16:02     ` Stephen Warren [this message]
2013-08-19  8:36       ` Caizhiyong
2013-08-19 16:05         ` Stephen Warren
2013-09-17 11:15 ` Linus Walleij
2013-09-17 13:08   ` Caizhiyong
  -- strict thread matches above, loose matches on Subject: below --
2013-07-27 13:56 Caizhiyong
2013-07-30 23:13 ` Andrew Morton
2013-07-31 13:25 ` Karel Zak
2013-08-01  1:46   ` Caizhiyong

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=520E4D1F.3000509@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=akpm@linux-foundation.org \
    --cc=albert.wanglin@huawei.com \
    --cc=caizhiyong@huawei.com \
    --cc=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quyaxin@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox