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@codethink.co.uk
First, this should be v10 not "RESEND". And that means the next version should be v11.
okOne 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/mx53locothe 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 mirrorsof 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.