[U-Boot] [PATCH RESEND] Introduced btrfs file-system with btrload command

[Tom Rini]

On Thu, Mar 28, 2013 at 05:45:33PM +0000, Adnan Ali wrote:
> On 28/03/13 17:04, Tom Rini wrote:
> >On Thu, Mar 21, 2013 at 02:04:45PM +0000, Adnan Ali wrote:
> >
> >>Introduces btrfs file-system to read file from
> >>volume/sub-volumes with btrload command. This
> >>implementation has read-only support.
> >>This btrfs implementation is based on syslinux btrfs
> >>code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.
> >>
> >>v9:     patch problem reworked.
> >>v8:     patch problem reworked.
> >>v5:     merged with master.
> >>v4:     btrls command added.
> >>
> >>Signed-off-by: Adnan Ali <adnan.ali at codethink.co.uk>
> >First, this should be v10 not "RESEND".  And that means the next version
> >should be v11.
>      ok
> >
> >One of the rules of adding code to U-Boot is we don't add "dead" code
> >that's not built somewhere.  So you should be adding CONFIG_CMD_BTR
> >somewhere like to say include/configs/sandbox.h (which has ext4/fat
> >support, but can't yet use them).
>      You mean adding to one of the configs, I used include/configs/mx53loco
>   the reason i didn't added config file to patch as some one told not to
> add config file as part of port. Is that what you mean.

Yes, true.  But that's what multi-part series are for.  Patch 1, add the
code, patch 2, enable it.

> >Another rule is no adding code with compiler warning.  This code has
> >_a_lot_ of warnings.  This is due in part to how you've ported the
> >syslinux generic inode/fs_info structure over to U-Boot (as we need to
> >spend some time here cleaning up our code, but I'm not asking you to do
> >that).  I started digging into fixing these warnings but then found your
>     Thanks if you are doing it.

At some point after your patch and I'll clean up btrfs, yes.

> >changes to btrfs_read_super_block() where you removed the syslinux check
> >over all possible superblock areas.  Why are we deviating here?  Are
> >there other deviations from syslinux in the driver itself?  Thanks.
> >
>      The first super is the real one the rest of them are just mirrors
> of the first .  If you want it to be added i can do it.

Well, not exactly.  If I follow both the code and comments, and my
recollection of one of the btrfs talks, it's possible that the first
superblock isn't the most recent one, hence checking them all so that we
start off with the most recent one.  So yes please, lets stay in sync.

But that's the only implementation deviation you made from the syslinux
code?  Thanks.

-- 
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/20130328/b68892dd/attachment.pgp>