Re: About the code style requirement

[Qu Wenruo]

On 2021/10/1 14:08, Vladimir 'phcoder' Serbinenko wrote:
> On Fri, Oct 1, 2021 at 2:13 AM Qu Wenruo <wqu@suse.com> wrote:
> > On 2021/9/30 18:51, Qu Wenruo wrote:
> > > On 2021/9/30 18:20, Vladimir 'phcoder' Serbinenko wrote:
> > > > Le jeu. 30 sept. 2021, 00:24, Qu Wenruo <wqu@suse.com
> > > > <mailto:wqu@suse.com>> a écrit :
> > > >
> > > >
> > > >
> > > >      On 2021/9/29 23:38, Lennart Sorensen wrote:
> > > >       > On Wed, Sep 29, 2021 at 03:04:59PM +0800, Qu Wenruo via
> > > >      Grub-devel wrote:
> > > >       >> Oh, didn't know there would be license problem.
> > > >       >
> > > >       > There often is. :)
> > > >       >
> > > >       >> Then it would be complex.
> > > >       >>
> > > >       >> Quite some code is directly copied from kernel without
> > > >      modification, those
> > > >       >> should still be GPL-2.0 only.
> > > >       >>
> > > >       >> For code already cross-ported to U-boot, it's GPL-2.0+, I guess
> > > >      it would be
> > > >       >> OK there.
> > > >       >>
> > > >       >> But from what I see in btrfs-progs, most of them is still GPL
> > > > 2.0.
> > > >       >>
> > > >       >> I guess during the cross-port to U-boot, I have already broken
> > > >      the GPL 2.0
> > > >       >> requirement...
> > > >       >>
> > > >       >> Any advice on this problem?
> > > >       >
> > > >       > Does libbtrfsutils provide what you need?  It appears to be
> > > >      LGPLv2.1+.
> > > >       >
> > > >
> > > >      Unfortunately no.
> > > >
> > > >      BTW, U-boot is GPL v2.0+, would it be possible to cross port from
> > > >      U-boot?
> > > >
> > > >      For the worst case I can craft a new interface from scratch, as GRUB
> > > >      doesn't seem to need any write operation for the fs, thus quite some
> > > >      code can be truncated and all transaction related functionality
> > > > can be
> > > >      removed.
> > > >
> > > > Sorry but this still doesn't cut it.
> > >
> > > Isn't GPLv2.0+ of U-boot compatible with the GPLv3.0+ of GRUB?
> > >
> > > > If you use the code, even if you adapt it, you need permission from
> > > > original authors, either as a license or as a relicensing permission.
> > > > I sometimes get asked for relicensing of the code I wrote and I often
> > > > grant this request. Asking original authors may be worth it.
> > >
> > > In this U-boot case, the code is cross-ported from btrfs-progs by
> > > myself, I can think of 3 or 4 other authors involved doing small bug
> > > fixes in U-boot realm, thus asking for permission of U-boot code should
> > > be pretty simple.
> > >
> > > But there are still code copied from kernel into U-boot, without
> > > modification.
> > >
> > > Does it still prevent those kernel code from being used in GRUB?
> > >
> > > > Otherwise you're allowed to study the documentation and write code
> > > > based from it. What you're allowed more than this depends on
> > > > jurisdiction.
> > >
> > > Sure, in fact since GRUB doesn't require write support for the fs, I can
> > > craft a different interface and start from scratch.
> > >
> > > But I still hope to get the license thing more clear, other than
> > > starting a new (and less functional) btrfs code.
> >
> > After some chats with guys in SUSE, it's definitely a no-no to share any
> > code from those projects.
> >
> > So I'll just start from scratch to craft a read-only btrfs
> > implementation inside GRUB.
>
> GRUB already has a btrfs implementation. Writing new one from scratch
> instead of existing one is unwelcome. From scratch means new bugs.
> Do you have problems with existing implementation?

In fact, quite some:

- Can't read shared data extents of reflinked files
  This can be fixed without a big refactor.

- No csum verification
- No support for extra checksums (xxhash/sha256/blake2)
- No very basic tree block sanity check
  The only sanity check is bytenr and fsid, which is far from ideal.
  The most deadly case like parent-child tree block level mismatch is
  not handled at all.
  (which can easily cause a dead loop,
   e.g. tree_block1 -> tree_block2 -> tree_block 1)

> If so I prefer you
> to fix the exact bugs rather than attempt to rewrite the entire thing
> from scratch

If only for the read failure of the reflinked files, I'd be pretty happy 
just to fix that bug.

But for the long run, I really prefer to have a more-or-less common base 
which every btrfs developer can easily start their work easily.

Your work on the existing grub btrfs code is very appreciated, but I'm 
not sure if it is the best solution in the long run.

Thus please let us btrfs developers to contribute our experience to make 
a better and more unified implementation.
(Although still less unified due to license conflicts)

Thanks,
Qu