U-Boot btrfs implementation - will there by syncing?

[Qu Wenruo]

On 2021/12/17 07:05, Marek Behún wrote:
> Hello Qu and others,
>
> one of the points of Qu's reimplementation of U-Boot's btrfs code that
> made it somehow synced with btrfs-progs, was that the old
> implementation was, quote
>
>    pretty different from btrfs-progs nor kernel, making it pretty hard to
>    sync code between different projects
>
> Another point was that afterwards Qu wanted to bring some of the missing
> btrfs features into U-Boot, since they should be much easier to
> implement after the reimplementation.
>
> I was looking at current btrfs-progs, and noticed that there were many
> changes since then, but only one or two were ever synced to U-Boot.

Yep, those changes are mostly preparation for the incoming extent-tree
v2 feature, they bring no real behavior change for now.

And I'm planning to cross-port them just to make later cross-port easier.

Thanks for the reminder.

>
> I would like to know if Qu, or anyone else, is planning to do this
> code-syncing, and maybe implement some of the missing features?
>
> The reason I am asking this is that in the meantime I've reached the
> opinion that the idea of code-syncing in this sense almost never really
> works. It is usually proposed by one person who ports the code from
> another project, and then keeps it synced for a time, but then stops
> doing it because they have too much other work, or change employer, or
> another reason.
>
> It happened multiple times. One example is U-Boot's Hush shell, which
> was imported from busybox, with the intention to keep it in sync, but
> the reality is that U-Boot's implementation is now years (decade?) old,
> and there were so many ad-hoc fixes done in U-Boot that currently the
> only way to sync is basically to change the whole code (which will also
> cause issues with existing user scripts, but maybe it should be done
> anyway).
>
> Another reason why I am writing this is that I think that with the
> amount of work Qu put into that reimplementation last year, he could
> have instead implemented some of the new features in the old
> implementation and spend a similar amount of time doing that, and the
> result would be those new features in U-Boot for over a year by now.

I doubt that, the original interface is completely different than the
interface we have in kernel/progs.

That means, if one wants to cross port the recent extent-tree v2
changes, it will be a hell.

So in the long run, it's still beneficial, even they get de-synced somehow.

>
> Also, I've come to the opinion that maybe two different and maintained
> implementations are a good thing for such a project as a filesystem,
> similar to how multiple implementations of C/C++ compiler are a good
> thing.
>
> For the last few months I was on-and-off thinking about whether it
> would make sense to revert to the original implementation and then
> implement some of the missing features. But it would not make sense if
> Qu, or anyone else, is planning to do that code syncing and bringing of
> new features from btrfs-progs, so that's why I am asking.

The worst example for different implementations are another bootloader,
GRUB.

Its btrfs implementation has way less features, no sanity checks, and is
super easy to craft an image to cause infinite loop for GRUB.
And it even can not handle the new default mkfs features (NO_HOLES,
which is there for long long time).

Thus I even re-implemented a new license compatible project from
scratch, btrfs-fuse, to provide a basis for later cross-port.
(That only has read-only support, and is mostly MIT licesnsed, the
interface is almost the same as progs/kernel).

It may be possible for simpler filesystems, but for complex filesysmtes
like btrfs, a completely different implementation with completely
different interfaces is really not an ideal situation.

I don't really want to do it again and again, using different (and
sometimes very crappy) interfaces to do the same work.

Thanks,
Qu

>
> Please give your opinions, people.
>
> Thanks.
>
> Marek