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 <swar...@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 <swar...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
