On 2021/10/1 14:08, Vladimir 'phcoder' Serbinenko wrote:
On Fri, Oct 1, 2021 at 2:13 AM Qu Wenruo <w...@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 <w...@suse.com
<mailto:w...@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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
