All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3 3/8] disk: introduce get_device()
Date: Fri, 21 Sep 2012 10:09:52 -0600	[thread overview]
Message-ID: <505C9150.6040206@wwwdotorg.org> (raw)
In-Reply-To: <505C6354.6010604@gmail.com>

On 09/21/2012 06:53 AM, Rob Herring wrote:
> On 09/18/2012 05:37 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> This patch introduces function get_device(). This looks up a
>> block_dev_desc_t from an interface name (e.g. mmc) and device number
>> (e.g. 0). This function is essentially the non-partition-specific
>> prefix of get_device_and_partition().

>> +int get_device(const char *ifname, const char *dev_str,
>> +	       block_dev_desc_t **dev_desc)
>> +{
>> +	char *ep;
>> +	int dev;
>> +
> 
> Why don't you look up bootdevice here? That would be more consistent
> behavior.

bootdevice names a partition (or can name a partition), whereas this
function is about retrieving a device handle and never a partition handle.

I'm not sure it makes semantic sense to always fall back to bootdevice
for commands that call get_device() directly. I'd far prefer people to
always just pass the device they want to a command rather than relying
implicitly on environment variables.

If we did read bootdevice here, we'd end up having to read/parse it in
both get_device() and get_device_and_partition(), here to extract just
the device portion and in get_device_and_partition() to extract just the
partition portion. And we'd have to make sure the code here only allowed
the user to specify a partition /if/ this function was called from
get_device_and_partition() and not if a command called it directly. That
all seems a bit complex.

  reply	other threads:[~2012-09-21 16:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18 22:37 [U-Boot] [PATCH V3 0/8] disk: "part" command and dependencies Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 1/8] disk: parameterize get_device_and_partition's loop count Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 2/8] disk: fix get_device_and_partition() bootable search Stephen Warren
2012-09-19  1:18   ` Rob Herring
2012-09-18 22:37 ` [U-Boot] [PATCH V3 3/8] disk: introduce get_device() Stephen Warren
2012-09-19  1:21   ` Rob Herring
2012-09-19  1:25     ` Rob Herring
2012-09-19 17:18       ` Stephen Warren
2012-09-19 18:17       ` Tom Rini
2012-09-21 12:53   ` Rob Herring
2012-09-21 16:09     ` Stephen Warren [this message]
2012-09-18 22:37 ` [U-Boot] [PATCH V3 4/8] disk: get_device_and_partition() enhancements Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 5/8] disk: part_efi: range-check partition number Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 6/8] disk: part_efi: parse and store partition UUID Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 7/8] disk: part_msdos: " Stephen Warren
2012-09-18 22:37 ` [U-Boot] [PATCH V3 8/8] cmd_part: add partition-related command Stephen Warren

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=505C9150.6040206@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=u-boot@lists.denx.de \
    /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.