[9front] distproto: include the files in /lib/firmware/*

[9front] distproto: include the files in /lib/firmware/*

[kemal]

Some people might put firmware files in /lib/firmware before they boot
up their installation disk if their wifi/ethernet card requires a
firmware blob and that card is their only possible access to a network.

diff -r 85895476fecf sys/lib/sysconfig/proto/distproto
--- a/sys/lib/sysconfig/proto/distproto	Tue Mar 02 22:56:58 2021 -0500
+++ b/sys/lib/sysconfig/proto/distproto	Sun Mar 07 19:50:38 2021 +0300
@@ -22,6 +22,7 @@
 	face	d775
 		+
 	firmware	d775
+		*
 	font	d775
 		bit	d775
 			+

Re: [9front] distproto: include the files in /lib/firmware/*

[ori]

Quoth kemal <kemali13@protonmail.com>:
> Some people might put firmware files in /lib/firmware before they boot
> up their installation disk if their wifi/ethernet card requires a
> firmware blob and that card is their only possible access to a network.
> 
> diff -r 85895476fecf sys/lib/sysconfig/proto/distproto
> --- a/sys/lib/sysconfig/proto/distproto	Tue Mar 02 22:56:58 2021 -0500
> +++ b/sys/lib/sysconfig/proto/distproto	Sun Mar 07 19:50:38 2021 +0300
> @@ -22,6 +22,7 @@
>  	face	d775
>  		+
>  	firmware	d775
> +		*
>  	font	d775
>  		bit	d775
>  			+
> 

I think it'd make more sense to just build them into the kernel
in this case.

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> I think it'd make more sense to just build them into the kernel
> in this case.

If somebody does not have a 9front installation, they would have
to install a 9front VM to build a kernel. In this case, putting
it into /lib/firmware is better.

Re: [9front] distproto: include the files in /lib/firmware/*

[ori]

Quoth kemal <kemali13@protonmail.com>:
> > I think it'd make more sense to just build them into the kernel
> > in this case.
> 
> If somebody does not have a 9front installation, they would have
> to install a 9front VM to build a kernel. In this case, putting
> it into /lib/firmware is better.
> 

If they don't have a 9front installation, how are
they going to use this change? I don't think we're
going to start redistributing Intel's firmware,
because legal reasons:

	https://en.wikipedia.org/wiki/Freely_redistributable_software

(I'm not a lawyer, it'd be nice to be wrong on this)

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> If they don't have a 9front installation, how are
> they going to use this change?

Mention it on the FQA?

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> I don't think we're going to start redistributing Intel's
> firmware, because legal reasons:
>
> https://en.wikipedia.org/wiki/Freely_redistributable_software
>
> (I'm not a lawyer, it'd be nice to be wrong on this)

I have checked the firmware license now. Redistribution seems to
be permitted without tampering. In addition, patent license
actually covers Plan 9. Leaving a copy below.

Copyright (c) 2006-2015, Intel Corporation.
All rights reserved.

Redistribution.  Redistribution and use in binary form, without
modification, are permitted provided that the following conditions are
met:

* Redistributions must reproduce the above copyright notice and the
  following disclaimer in the documentation and/or other materials
  provided with the distribution.
* Neither the name of Intel Corporation nor the names of its suppliers
  may be used to endorse or promote products derived from this software
  without specific prior written permission.
* No reverse engineering, decompilation, or disassembly of this software
  is permitted.

Limited patent license.  Intel Corporation grants a world-wide,
royalty-free, non-exclusive license under patents it now or hereafter
owns or controls to make, have made, use, import, offer to sell and
sell ("Utilize") this software, but solely to the extent that any
such patent is necessary to Utilize the software alone, or in
combination with an operating system licensed under an approved Open
Source license as listed by the Open Source Initiative at
http://opensource.org/licenses.  The patent license shall not apply to
any other combinations which include this software.  No hardware per
se is licensed hereunder.

DISCLAIMER.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> > I don't think we're going to start redistributing Intel's
> > firmware, because legal reasons:
> > https://en.wikipedia.org/wiki/Freely_redistributable_software
> > (I'm not a lawyer, it'd be nice to be wrong on this)
>
> I have checked the firmware license now. Redistribution seems to
> be permitted without tampering. In addition, patent license
> actually covers Plan 9. Leaving a copy below.

Would like to add this, Ralink seems to use the same license,
just all mentions of "Intel Corporation" is replaced with
"Ralink Technology Corporation".

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/LICENCE.ralink-firmware.txt

(i am also not a lawyer of course)

Re: [9front] distproto: include the files in /lib/firmware/*

[hiro]

the only downside i see is the purity of our distro...
right now it contains just stuff that can be generated from the
source, and maybe some fonts or a few small icons/graphics are the
only binary content

On 3/8/21, kemal <kemali13@protonmail.com> wrote:
>> > I don't think we're going to start redistributing Intel's
>> > firmware, because legal reasons:
>> > https://en.wikipedia.org/wiki/Freely_redistributable_software
>> > (I'm not a lawyer, it'd be nice to be wrong on this)
>>
>> I have checked the firmware license now. Redistribution seems to
>> be permitted without tampering. In addition, patent license
>> actually covers Plan 9. Leaving a copy below.
>
> Would like to add this, Ralink seems to use the same license,
> just all mentions of "Intel Corporation" is replaced with
> "Ralink Technology Corporation".
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/LICENCE.ralink-firmware.txt
>
> (i am also not a lawyer of course)
>
>

Re: [9front] distproto: include the files in /lib/firmware/*

[sirjofri]

08.03.2021 12:10:55 hiro <23hiro@gmail.com>:
> the only downside i see is the purity of our distro...
> right now it contains just stuff that can be generated from the
> source, and maybe some fonts or a few small icons/graphics are the
> only binary content

I think it is very convenient to have some firmware in the released iso 
images. I wouldn't add them to the repo, adding links to them like the 
fqa already does is good enough, I think. Since we have the /lib/firmware 
directory and it's basically enough to place the files there I don't 
think too many adjustments are needed, adding mkfile rules for 
downloading the firmware files and packing an iso would be convenient for 
automatic packing (I am thinking about doing daily iso images on a server 
as well as providing a mirror for 9front isos. Imagine a rule for the 
bare iso without firmware and another rule for release isos with 
firmware).

(I am not a lawyer.)

Just my two cents.

sirjofri

Re: [9front] distproto: include the files in /lib/firmware/*

[Sigrid Solveig Haflínudóttir]

Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>:
> 08.03.2021 12:10:55 hiro <23hiro@gmail.com>:
> > the only downside i see is the purity of our distro...
> > right now it contains just stuff that can be generated from the
> > source, and maybe some fonts or a few small icons/graphics are the
> > only binary content
> 
> I think it is very convenient to have some firmware in the released iso 
> images. I wouldn't add them to the repo, adding links to them like the 
> fqa already does is good enough, I think. Since we have the /lib/firmware 
> directory and it's basically enough to place the files there I don't 
> think too many adjustments are needed, adding mkfile rules for 
> downloading the firmware files and packing an iso would be convenient for 
> automatic packing (I am thinking about doing daily iso images on a server 
> as well as providing a mirror for 9front isos. Imagine a rule for the 
> bare iso without firmware and another rule for release isos with 
> firmware).
> 
> (I am not a lawyer.)
> 
> Just my two cents.
> 
> sirjofri

Another way would be to have enough space on FAT parition to copy
firmware to ("firmware" directory on that partition) and to bind it on
top of /lib/firmware during boot process.  ISO stays the same, the
user is free to copy firmware as they please after writing the ISO to
USB flash drive or whatever.

I'm against distributing Intel's (or whomever) binary crap in the
default ISO.  There WILL be a point where it's going to be either old
or missing.

Re: [9front] distproto: include the files in /lib/firmware/*

[Julien Blanchard]

> Le 8 mars 2021 à 13:19, Sigrid Solveig Haflínudóttir <ftrvxmtrx@gmail.com> a écrit :
> 
> Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>:
>> 08.03.2021 12:10:55 hiro <23hiro@gmail.com>:
>>> the only downside i see is the purity of our distro...
>>> right now it contains just stuff that can be generated from the
>>> source, and maybe some fonts or a few small icons/graphics are the
>>> only binary content
>> 
>> I think it is very convenient to have some firmware in the released iso 
>> images. I wouldn't add them to the repo, adding links to them like the 
>> fqa already does is good enough, I think. Since we have the /lib/firmware 
>> directory and it's basically enough to place the files there I don't 
>> think too many adjustments are needed, adding mkfile rules for 
>> downloading the firmware files and packing an iso would be convenient for 
>> automatic packing (I am thinking about doing daily iso images on a server 
>> as well as providing a mirror for 9front isos. Imagine a rule for the 
>> bare iso without firmware and another rule for release isos with 
>> firmware).
>> 
>> (I am not a lawyer.)
>> 
>> Just my two cents.
>> 
>> sirjofri
> 
> Another way would be to have enough space on FAT parition to copy
> firmware to ("firmware" directory on that partition) and to bind it on
> top of /lib/firmware during boot process.  ISO stays the same, the
> user is free to copy firmware as they please after writing the ISO to
> USB flash drive or whatever.
> 
> I'm against distributing Intel's (or whomever) binary crap in the
> default ISO.  There WILL be a point where it's going to be either old
> or missing.

Maybe something like OpenBSD does where a tool will try to download the firmwares after installation?

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

(also, is 9front ml shitting itself again? i take some messages late.)

> Another way would be to have enough space on FAT parition to copy
> firmware to ("firmware" directory on that partition) and to bind it on
> top of /lib/firmware during boot process.  ISO stays the same, the
> user is free to copy firmware as they please after writing the ISO to
> USB flash drive or whatever.

My original intention of this patch is very close to this. The diff
changes distproto so that copydist will also copy firmwares in /lib/firmware/*.
This way, user can put fws to /lib/firmware after writing the iso to the USB,
then they don't have boot again to another OS/use another device to take fws.
We would also warn the novice users to put fws before they boot up the USB
in the FQA.

If we are going to put fws to the distribution, we should put it into just
ISO as some firmwares (8260 and 9260 fws) take 2MB of space. Putting this
big of files into the repo is not a good idea.

> There WILL be a point where it's going to be either old
> or missing.

Speaking of old... OpenBSD's fw tarball is outdated, they provide version
34 I think for 8260+ series but 8260's latest version is 36 and 9260 has
version 46!!!!!!!! See:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/

> Maybe something like OpenBSD does where a tool will try to download the firmwares after installation?

The purpose of the diff was for the people who can access internet only through
wifi and their card requires fw.

Re: [9front] distproto: include the files in /lib/firmware/*

[hiro]

the reason i'd want it all built in is bec. then you can netboot over
wifi without needing an installation.

it feels wrong to put it into iso for purity reasons, but there is not
technical reason not to.
if some wifi firmware is outdated, bad luck, wrongly depending on wifi
serves you in that instance. if not, all the better, at least some
lucky souls can get going faster and do something useful instead of
managing their firmware files.

at first sigrid's argument convinced me, but now that i realize it
doesn't solve the problem i am even more convinced, there just isn't
enough of a downside to include it from the beginning.

and since i'm not here to convince but to enlighten i will add one
more counterargument, the only other downside that i missed till now:

it increases the size of the kernel image. might suck bec. tftp is already slow!

On 3/8/21, kemal <kemali13@protonmail.com> wrote:
> (also, is 9front ml shitting itself again? i take some messages late.)
>
>> Another way would be to have enough space on FAT parition to copy
>> firmware to ("firmware" directory on that partition) and to bind it on
>> top of /lib/firmware during boot process.  ISO stays the same, the
>> user is free to copy firmware as they please after writing the ISO to
>> USB flash drive or whatever.
>
> My original intention of this patch is very close to this. The diff
> changes distproto so that copydist will also copy firmwares in
> /lib/firmware/*.
> This way, user can put fws to /lib/firmware after writing the iso to the
> USB,
> then they don't have boot again to another OS/use another device to take
> fws.
> We would also warn the novice users to put fws before they boot up the USB
> in the FQA.
>
> If we are going to put fws to the distribution, we should put it into just
> ISO as some firmwares (8260 and 9260 fws) take 2MB of space. Putting this
> big of files into the repo is not a good idea.
>
>> There WILL be a point where it's going to be either old
>> or missing.
>
> Speaking of old... OpenBSD's fw tarball is outdated, they provide version
> 34 I think for 8260+ series but 8260's latest version is 36 and 9260 has
> version 46!!!!!!!! See:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
>
>> Maybe something like OpenBSD does where a tool will try to download the
>> firmwares after installation?
>
> The purpose of the diff was for the people who can access internet only
> through
> wifi and their card requires fw.
>
>
>
>
>
>
>

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> the reason i'd want it all built in is bec. then you can netboot over
> wifi without needing an installation.

Do you mean into to the kernel? Well, that can be a good reason.

Also just realised, is merging the fw in to the kernel is legal?
License gives you permission to **just** redistribute and use,
I don't know if building it into the kernel can be count as
"modification".

Re: [9front] distproto: include the files in /lib/firmware/*

[hiro]

yes and yes.

in terms of being hunted down by powerful rich assholes with money and
lawyers, we're obviously at the mercy of our lack of relevance. that's
the only thing that protects us. and perhaps common decency (i can
never be sure about it but i can hope).

it doesn't matter whether it seems like a modification to YOU.
somebody with enough money can make any court believe that looking
wrongly at the binary is already a violation of somebody's unalienable
human right or similar bullshit.

On 3/8/21, kemal <kemali13@protonmail.com> wrote:
>> the reason i'd want it all built in is bec. then you can netboot over
>> wifi without needing an installation.
>
> Do you mean into to the kernel? Well, that can be a good reason.
>
> Also just realised, is merging the fw in to the kernel is legal?
> License gives you permission to **just** redistribute and use,
> I don't know if building it into the kernel can be count as
> "modification".
>

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> in terms of being hunted down by powerful rich assholes with money and
> lawyers, we're obviously at the mercy of our lack of relevance. that's
> the only thing that protects us. and perhaps common decency (i can
> never be sure about it but i can hope).

i would ***NEVER AND NEVER*** take the risk. it's a damn big risk
that can cause big problems.

Re: [9front] distproto: include the files in /lib/firmware/*

[hiro]

if you don't want risks you shouldn't do anything, ever.

On 3/8/21, kemal <kemali13@protonmail.com> wrote:
>> in terms of being hunted down by powerful rich assholes with money and
>> lawyers, we're obviously at the mercy of our lack of relevance. that's
>> the only thing that protects us. and perhaps common decency (i can
>> never be sure about it but i can hope).
>
> i would ***NEVER AND NEVER*** take the risk. it's a damn big risk
> that can cause big problems.
>

Re: [9front] distproto: include the files in /lib/firmware/*

[Stanley Lieber]

On March 8, 2021 7:55:31 AM EST, hiro <23hiro@gmail.com> wrote:
>the reason i'd want it all built in is bec. then you can netboot over
>wifi without needing an installation.
>
>it feels wrong to put it into iso for purity reasons, but there is not
>technical reason not to.
>if some wifi firmware is outdated, bad luck, wrongly depending on wifi
>serves you in that instance. if not, all the better, at least some
>lucky souls can get going faster and do something useful instead of
>managing their firmware files.
>
>at first sigrid's argument convinced me, but now that i realize it
>doesn't solve the problem i am even more convinced, there just isn't
>enough of a downside to include it from the beginning.
>
>and since i'm not here to convince but to enlighten i will add one
>more counterargument, the only other downside that i missed till now:
>
>it increases the size of the kernel image. might suck bec. tftp is already slow!
>
>On 3/8/21, kemal <kemali13@protonmail.com> wrote:
>> (also, is 9front ml shitting itself again? i take some messages late.)
>>
>>> Another way would be to have enough space on FAT parition to copy
>>> firmware to ("firmware" directory on that partition) and to bind it on
>>> top of /lib/firmware during boot process.  ISO stays the same, the
>>> user is free to copy firmware as they please after writing the ISO to
>>> USB flash drive or whatever.
>>
>> My original intention of this patch is very close to this. The diff
>> changes distproto so that copydist will also copy firmwares in
>> /lib/firmware/*.
>> This way, user can put fws to /lib/firmware after writing the iso to the
>> USB,
>> then they don't have boot again to another OS/use another device to take
>> fws.
>> We would also warn the novice users to put fws before they boot up the USB
>> in the FQA.
>>
>> If we are going to put fws to the distribution, we should put it into just
>> ISO as some firmwares (8260 and 9260 fws) take 2MB of space. Putting this
>> big of files into the repo is not a good idea.
>>
>>> There WILL be a point where it's going to be either old
>>> or missing.
>>
>> Speaking of old... OpenBSD's fw tarball is outdated, they provide version
>> 34 I think for 8260+ series but 8260's latest version is 36 and 9260 has
>> version 46!!!!!!!! See:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
>>
>>> Maybe something like OpenBSD does where a tool will try to download the
>>> firmwares after installation?
>>
>> The purpose of the diff was for the people who can access internet only
>> through
>> wifi and their card requires fw.
>>
>>
>>
>>
>>
>>
>>
>

what happens when the is fills up?

just all the common intel firmware from openbsd's tarball creates a >20mb kernel.

386 sometimes chokes when trying to boot a >20mb kernel. found this out the hard way.

sl

Re: [9front] distproto: include the files in /lib/firmware/*

[cinap_lenrek]

yeah, and with each firmware, the interface and message formats between the
driver and the firmware can completely change. linux solves this with a
gigant message translation layer to the point where it becomes impossible
to understand what exactly it sends to the firmware.

and there is NO DOCUMENTATION for any of this.

while the openbsd (and inspired 9front) driver sticks to a specific firmware
version.

if you want to update the firmware, you also need to revisit the driver
and reverse engineer what linux does with this exact firmware revision
and card.

--
cinap

Re: [9front] distproto: include the files in /lib/firmware/*

[kemal]

> yeah, and with each firmware, the interface and message formats between the
> driver and the firmware can completely change. linux solves this with a
> gigant message translation layer to the point where it becomes impossible
> to understand what exactly it sends to the firmware.
>
> and there is NO DOCUMENTATION for any of this.
>
> while the openbsd (and inspired 9front) driver sticks to a specific firmware
> version.
>
> if you want to update the firmware, you also need to revisit the driver
> and reverse engineer what linux does with this exact firmware revision
> and card.

thank you for informing, i thought fw updates just fixed bugs and added
new interfaces, like a normal FUCKING fw i guess.

Re: [9front] distproto: include the files in /lib/firmware/*

[Stanley Lieber]

On March 8, 2021 6:58:49 AM EST, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>08.03.2021 12:10:55 hiro <23hiro@gmail.com>:
>> the only downside i see is the purity of our distro...
>> right now it contains just stuff that can be generated from the
>> source, and maybe some fonts or a few small icons/graphics are the
>> only binary content
>
>I think it is very convenient to have some firmware in the released iso 
>images. I wouldn't add them to the repo, adding links to them like the 
>fqa already does is good enough, I think. Since we have the /lib/firmware 
>directory and it's basically enough to place the files there I don't 
>think too many adjustments are needed, adding mkfile rules for 
>downloading the firmware files and packing an iso would be convenient for 
>automatic packing (I am thinking about doing daily iso images on a server 
>as well as providing a mirror for 9front isos. Imagine a rule for the 
>bare iso without firmware and another rule for release isos with 
>firmware).
>
>(I am not a lawyer.)
>
>Just my two cents.
>
>sirjofri
>

how do we decide which firmware to include and which firmware to ignore?

sl