From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Behun <marek.behun@nic.cz>
Date: Thu, 9 Apr 2020 15:24:43 +0200
Subject: Btrfs and endian convert
In-Reply-To: <8b50295b-eaa7-98c9-33c2-128a0fe9819d@gmx.com>
References: <4fb08694-185b-a708-7f6b-b77f95f665ee@gmx.com>
 <8b50295b-eaa7-98c9-33c2-128a0fe9819d@gmx.com>
Message-ID: <20200409152443.57f2bc2c@nic.cz>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thu, 9 Apr 2020 14:53:47 +0800
Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:

> On 2020/4/9 ??2:27, Qu Wenruo wrote:
> > Hi Marek,
> > 
> > I respect your independent implementation of btrfs inside U-boot, but it
> > looks like the code is too creative, other than follow the regular btrfs
> > code.
> > 
> > One of the biggest problem is, there is no convert of on-disk endian and
> > in-memory endian.
> > 
> > The most obvious proof is the lack of btrfs_disk_key, on-disk
> > btrfs_disk_key is returned and used against native endian btrfs_key.
> > 
> > Is U-boot only supposed to be run on little endian system?  
> 

It supports big endian as well.

> My bad, you do the convert the convert at different timing.

I never tested it on big endian, but conv-funcs.h should do it...

> For header and item/node ptr, it's converted as tree block read time,
> while for other structures, you do the convert when reading them.
> 
> This is pretty different from what we do in kernel/progs.

Yes, unfortunately.

> > 
> > And, would you mind me to do the full cross port of btrfs-progs code to
> > U-boot?
> > I found a lot of practice pretty far away from the common code base of
> > btrfs-progs and kernel, like using on-disk key pointer a lot (which
> > should be avoid due to endian convert).
> > 
> > Mind me to re-build the btrfs implementation from scratch?  
> 
> While this still stands, as latest btrfs_tree.h would include both
> btrfs_key and btrfs_disk_key, if we really want to sync the header, we
> still need to go the regular BTRFS_SETGET_* macros way.

If you think it will grow more fruit in the long way, go for it. What
is your main objective here? To support more features, like filesystem
on multiple devices, write support? Or just to be able to sync code so
that bugs are caught early?

Marek