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

[Alexandre Oliva]

On Oct 30, 2021, "Denis 'GNUtoo' Carikli" <GNUtoo at cyberdimension.org> wrote:

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

They're already (supposed to be) differentiated: the patterns that match
one case or another are (supposed to be) passed to different primitives,
even if they end up in the same mega regexp of stuff to remove.

The theory is that, if you don't wish to remove certain stuff, you can
disable the corresponding primitive in deblob-check.  That should get
you 90% of the way there.

If you find cases in which this is not so (quite possible), patches to
correct that would be welcome.

Patches to make things work for a purpose we don't share we probably be
a better fit for a downstream project.

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

*nod*, and that's probably the way to go for the librewritten future as
 well.

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

Sorry, get well soon!

>    And we are not in a situation to re-discuss the blocking of
>    all nonfree loadable firmwares either

We don't really insist on such blocking.  Indeed, for systems that
control other components and can ensure kernel-issued blob requests
don't induce users to install them, leaving the requests enabled would
be ideal.  But we're not in that position: our sources are to be usable
without inducing users to error even in such user-hostile environments
as systems that automatically attempt to install blobs when a driver
issues a request for them.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>