From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21810 invoked from network); 8 Mar 2021 15:55:56 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 8 Mar 2021 15:55:56 -0000 Received: from 5ess.inri.net ([107.191.111.177]) by 1ess; Mon Mar 8 10:50:01 -0500 2021 Received: from [127.0.0.1] ([104.59.85.219]) by 5ess; Mon Mar 8 10:32:37 -0500 2021 Date: Mon, 08 Mar 2021 10:32:35 -0500 From: Stanley Lieber To: 9front@9front.org In-Reply-To: References: <5B363A6921AF13A6394AA2B6B05DB843@gmail.com> Message-ID: <18645727-99FD-4D89-A6CD-C31C664F9993@stanleylieber.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: anonymous SQL over ORM descriptor polling STM-oriented STM framework Subject: Re: [9front] distproto: include the files in /lib/firmware/* Reply-To: 9front@9front.org Precedence: bulk On March 8, 2021 7:55:31 AM EST, hiro <23hiro@gmail=2Ecom> wrote: >the reason i'd want it all built in is bec=2E then you can netboot over >wifi without needing an installation=2E > >it feels wrong to put it into iso for purity reasons, but there is not >technical reason not to=2E >if some wifi firmware is outdated, bad luck, wrongly depending on wifi >serves you in that instance=2E if not, all the better, at least some >lucky souls can get going faster and do something useful instead of >managing their firmware files=2E > >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=2E > >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=2E might suck bec=2E tftp is al= ready slow! > >On 3/8/21, kemal wrote: >> (also, is 9front ml shitting itself again? i take some messages late=2E= ) >> >>> 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=2E ISO stays the same, the >>> user is free to copy firmware as they please after writing the ISO to >>> USB flash drive or whatever=2E >> >> My original intention of this patch is very close to this=2E The diff >> changes distproto so that copydist will also copy firmwares in >> /lib/firmware/*=2E >> This way, user can put fws to /lib/firmware after writing the iso to th= e >> USB, >> then they don't have boot again to another OS/use another device to tak= e >> fws=2E >> We would also warn the novice users to put fws before they boot up the = USB >> in the FQA=2E >> >> If we are going to put fws to the distribution, we should put it into j= ust >> ISO as some firmwares (8260 and 9260 fws) take 2MB of space=2E Putting = this >> big of files into the repo is not a good idea=2E >> >>> There WILL be a point where it's going to be either old >>> or missing=2E >> >> Speaking of old=2E=2E=2E OpenBSD's fw tarball is outdated, they provide= version >> 34 I think for 8260+ series but 8260's latest version is 36 and 9260 ha= s >> version 46!!!!!!!! See: >> >> https://git=2Ekernel=2Eorg/pub/scm/linux/kernel/git/firmware/linux-firm= ware=2Egit/tree/ >> >>> Maybe something like OpenBSD does where a tool will try to download th= e >>> firmwares after installation? >> >> The purpose of the diff was for the people who can access internet only >> through >> wifi and their card requires fw=2E >> >> >> >> >> >> >> > what happens when the is fills up? just all the common intel firmware from openbsd's tarball creates a >20mb = kernel=2E 386 sometimes chokes when trying to boot a >20mb kernel=2E found this out = the hard way=2E sl