Re: Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mi, 27.04.22 11:40, Neal Gompa (ngompa13@xxxxxxxxx) wrote:

> But I also strongly believe that it was a mistake to merge gummiboot
> into the systemd source tree because it creates all kinds of problems
> for distro maintenance, as I've already said earlier.

That's very vague. I still don#t get what those problems are
specifically supposed to be. Why can't you just have two srpm for the
same uptsream tarball? You keep suggesting things were all so
obviously untenable, but I never see an explanation why?

> Ita also discourages making the sd-boot code tighter and simpler
> since your primary focus is reuse across the tree rather than
> strictly separating the functional domains.

Dunno, as one of the developers of sd-boot I think this is a pretty
comprehensively bogus statement. Sharing code means less code,
duplicating code in multiple projects means more code. That should be
obvious.

Moreover, sd-boot is kinda simplistic. I did some sloccount analysis
for you:

<snip>
$ sloccount src/fundamental/ src/boot/efi/
SLOC	Directory	SLOC-by-Language (Sorted)
6117    efi             ansic=6117
797     fundamental     ansic=797
</snip>

i.e. that's the code linked into the uefi stuff. In fact, given it
also includes sd-stub it's a lot more than actually sd-boot.

And now compare with the supposedly simple "shim":

<snip>
SLOC	Directory	SLOC-by-Language (Sorted)
127120  Cryptlib        ansic=126650,sh=470
15633   top_dir         ansic=15019,sh=564,asm=50
3756    include         ansic=3756
2024    lib             ansic=2024
</snip>

Even if we ignore that it imports "Cryptlib", that's still like 3x as much code...

btw, grub is 283895 lines of code according to sloccount, just for
comparison...

So thank you very much, but I think we are good regarding
simplicity... I'd rather share more code with userspace, and thus have
less stuff to think about, get better testing and so on...

Lennart

--
Lennart Poettering, Berlin



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux