[blihp]

The Debian project has been historically a vocal proponent for open hardware/firmware/drivers etc. and here we are in 2023 having Debian somewhat controversially acknowledging that proprietary firmware may be required at least by some users, to some degree. So I am suggesting that if they really want to get there that they might need to help facilitate the change they would like to see.

Is RISC-V the be-all, end-all? No, but it could help them get a lot closer than they're likely to get with any of the proprietary ISAs.

[teddyh]

Debian is not a general advocacy organization. Debian produces the Debian GNU/Linux distribution, and that’s mostly it. The incentive to do the work necessary to add a new architecture to Debian must, in general, come from outside Debian itself. Debian will probably not, as a project, go around looking for new architectures to add. Debian depends on other people doing the work and presenting it to Debian, which will then distribute it if it is good enough. Debian will only have the motivation to work on including a new architecture if it is an obvious lacking feature of Debian – say, if every other Linux distributions supported an architecture, and it was widely used, but Debian did not support it, then the Debian project would have an incentive to work on it. But not before.

This is just like Debian generally does not write new useful software to put into Debian, and instead depend on outside, “upstream” authors to write software. Some other organizations, like FSF and its GNU project, will have advocacy roles, and do have the incentives to write new software and to help porting to new architectures. It is there that the motivations for this work must be found. Of course, individual people can be involved in more than one organization, and many Debian people happen to be enthusiastic advocates, and will in fact often do this work. But the reason for them doing this work is not, mostly, rooted in them being a part of Debian.

Therefore, and this is my point, if you want this work to be done, you can’t exhort Debian to do it. It will not work. Ask instead why someone else, whom you think should be motivated to do the work, does not do it.

[pabs3]

The RISC-V port of Debian was driven by internal Debian contributors, not by external actors. Similarly for Debian kFreeBSD and some other ports. OTOH, for LoongArch and ARC, those ports are driven almost entirely by the companies selling those chips. So I would say it is a mix.

[teddyh]

> The RISC-V port of Debian was driven by internal Debian contributors, not by external actors.

Yes, but my point is, they weren’t doing that work just because they were Debian contributors; they had their own additional reason for doing it. They were not assigned the work by Debian central command. Therefore, asking Debian why Debian does not do some work or other is usually the wrong way to get something done.

[pabs3]

Yes, there isn't much of a Debian central command, apart from the technical committee, but they can't force/direct people to do things, only to say what Debian will do in specific circumstances.

That said, the community of contributors are what makes up the Debian project, so in a sense it is Debian deciding to do things when Debian does things :)

[pabs3]

Even the open firmware that does exist has some major issues (like needing a proprietary compiler) or the hardware that it can run on it checks for Intel signatures, or only exists on archive.org, or is packaged in Debian but not properly built from source code, or exists but is only useful for obscure/ancient hardware that only people who want libre firmware buys, requires a forked compiler/toolchain to build, etc. Basically, open firmware is a hard problem and there aren't a lot of people with the skills and interest in doing it. I'm trying to at least document what exists on the wiki, anyone know of more projects?

https://wiki.debian.org/Firmware/Open

[pjmlp]

RISC-V doesn't close the door on proprietary extensions.

[snvzz]

Proprietary extensions need to live in the opcode space reserved for custom extensions, where it'll overlap with other vendors' own custom extensions.

If they conflict with RISC-V's own space, the chip can't use RISC-V trademarks.

And, of course, the RISC-V Consortium will never adopt proprietary extensions, as that goes against its core values.

[pjmlp]

What matters is what is on the market, and how it is made available.

Everything else matters as much as FSF point of view on something being free or not.

[snvzz]

That's why there are licenses and agreements.

So that we do not have to rely on anybody's goodwill.

[pjmlp]

And since RISC-V allows for extensions, all bets are off regarding successful deployments being extension free.

Just like many open core products that really need the full deal for being usable in a proper way.

Expecting otherwise is whishful thinking, or academia/maker community focus.

[snvzz]

There already are. As long as they're in custom space, there's no issue.