[U-Boot] [PATCH V3 2/4] FAT: make use of disk_partition_t.part

[Tom Rini]

On Mon, Oct 15, 2012 at 08:07:44PM +0200, Pavel Herrmann wrote:
> On Monday 15 of October 2012 10:40:25 Stephen Warren wrote:
> > On 10/13/2012 01:38 PM, Pavel Herrmann wrote:
> > > Hi
> > > 
> > > On Wednesday 10 October 2012 12:14:00 Stephen Warren wrote:
> > >> From: Stephen Warren <swarren at nvidia.com>
> > >> 
> > >> This removes the standalone cur_part_nr variable, opening the way to
> > >> replacing fat_register_device() with fat_set_blk_dev().
> > >> 
> > >> Note that when get_partition_info() fails and we use the entire disk,
> > >> the correct partition number is 0 (whole disk) not 1 (first partition),
> > >> so that change is also made here.
> > >> 
> > >> An alternative to this (and the previous) patch might be to simply
> > >> remove the partition number from the printf(). I don't know how attached
> > >> people are to it.
> > >> 
> > >> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> > > 
> > > Just as a heads up, in the DM any difference between a partition and a
> > > whole block device (also between different interfaces for disks) is
> > > hidden from any user code (code other than the one keeping track of
> > > partitions/disks, that only uses such information to determine whether to
> > > scan for partitions), you only get some object that can read/write blocks
> > > if you ask it nicely, and you have to make do with that (if you need more
> > > then you're probably doing something wrong).
> > > As a result, there is no notion of partition number, and the string you
> > > are
> > > patching up here (along with many others, due to unification of disk
> > > interfaces) is changed.
> > 
> > OK, so do you think it'd be better right now to drop patches 1 and 2 in
> > this series, and just remove the partition number from fat.c's printf()
> > call? That'd certainly be simple to do.
> 
> Well, in my case I have done a broader abstraction, that could be used for 
> non-continuous partitions as well (think LVM) with minimal effort (think extend 
> identifier structure used for searching to more than 
> interface:number:partnumber, no changes in FS code), and partition number 
> loses any meaning in that context.
> Whether dropping the number now is an acceptable change would be up to Tom 
> Rini, I would vote for it though, if that meant anything around here.

OK, lets rework this series as suggested here to make the DM work a
little easier.  Drop the print instead.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121017/712e7b43/attachment.pgp>