Linux-libre architecture and how to modify it for other uses cases?

[Denis 'GNUtoo' Carikli]

On Sun, 24 Oct 2021 12:27:39 -0300
Alexandre Oliva <lxoliva at fsfla.org> wrote:

> Hello, Denis, apologies for the huge delay in getting back to you.
> 
> On Oct 13, 2021, "Denis 'GNUtoo' Carikli" <GNUtoo at cyberdimension.org>
> wrote:
> 
> > As far as I know there are only two smartphones (The Openmoko
> > Freerunner and the Librem5) where the internal WiFi works without
> > requiring distributions to ship nonfree firmwares (this is because
> > the nonfree firmwares are integrated in a dedicated memory connected
> > directly to the WiFi chip).
> 
> Ooh, I didn't know the freerunner was like that.  I've always assumed
> it wouldn't work, and left it at that.
Given that the display controller, microSD controller and WiFi driver
(which is specific to the firmware on that flash chip) were never
upstreamed, so we'd have needed to unblob the vendor kernel.

Though we didn't have (and still don't have) any FSDG compliant
distributions that could support the CPU of that phone (armv4t).
And it only had 128M of RAM, so it would be even harder to support it
nowadays.

That's sad because it also contained a modem that can now run a fully
free firmware (osmocomBB). Unfortunately OsmocomBB is not meant for
regular use (it would require more work for that).

> > The part that I didn't manage to do yet and that looks complicated
> > for me is to find a way for Replicant to reuse the deblobing part
> > without reusing the firmware blocking part in a way that requires
> > the least amount of maintenance.
> 
> It's not so easy, indeed.  Though commenting out some of the
> reject_firmware and clean_blob entries in deblob-<kver>, and
> 'blobname' commands in deblob-check would likely get you the sources
> you wish, the blob requests and names would still be caught by the
> generic patterns that help us find new blob requests, so you'd either
> have to comment those out too, or add 'accept' commands to match and
> avoid flagging them.
I missed the accept commands. Thanks a lot.

[...]
> > What I didn't understand well is what deblob-check is supposed to do
> > beside finding binary code.
> 
> deblob-check has multiple behaviors depending on the command line
> options.
> 
> It scans source files, recognizing known acceptable patterns, flagging
> suspicious or known-unacceptable ones.
>
> It cleans up source files, keeping acceptable patterns and turning
> suspicious and unacceptable ones into /*(DEBLOBBED)*/.

What I'm interested in here is just to get rid of the blobs shipped by
Linux, not blocking the loading of nonfree firmwares[1], and here it's
not really clear which is which.

Is it somehow in the interest of the linux-libre project to accept
patches to differentiate both?

Though once I get something good enough, I'll probably also need to
find out how to adapt to the future model of linux-libre which will be
done without scripts.

> > The idea here is to enable people not familiar with linux-libre to
> > very easily rebase the Replicant changes on top of more recent
> > kernels versions, like we do with Linux, but while still keeping
> > deblobed kernels.
> 
> That's a laudable goal, but Linux changes so much from one version to
> another that there's no easy way to keep up without getting familiar
> with the cleaning-up scripts :-(
I fear that I'll have to do that at the end. 

In contrast, rebases against stock linux-libre are really easy to do,
especially now that there are git repositories of linux-libre. 

Thanks a lot to the people that worked on making it easier to reuse.
 
> I hope this helps.  I had planned to add more detailed thoughts on the
> general structure of deblob-check, but then you'd would have to wait
> longer, and those bits probably wouldn't help you much anyway.
Thanks a lot for all the information.

I'll get back to working on it as soon as I fix my really bad cold.

References:
-----------
[1]At the end of the day the real fix would be to reverse engineer the
   nonfree WiFi firmwares[2] to finally be able to use linux-libre +
   our paches on top, but we are not in a position to do that right now
   (we need to at least get Replicant 11 out before starting big
   projects like that, else the Replicant project would probably be
   dead). And we are not in a situation to re-discuss the blocking of
   all nonfree loadable firmwares either (we can't easily organize an
   in-person event to do that, and that is also something very time
   consuming to do). 

   So instead I need to release Alpha images for Replicant, and I need
   to make sure that they are fully free software to avoid further
   issues.

[2]Some people already have expressed some interest in doing that
   kind of reverse engineering work, and there have even been attempts
   to do it already which didn't succeed yet due to the lack of time.
   And there is also some work we might be able to reuse, though we'd
   need to look into it, especially to make sure it's free software and
   doesn't contain any nonfree code or data.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20211030/0601c888/attachment.sig>