linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080715173520.GA30521@1wt.eu>
Date:	Tue, 15 Jul 2008 19:35:20 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	arjan@...radead.org, akpm@...ux-foundation.org,
	dwmw2@...radead.org, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

On Tue, Jul 15, 2008 at 07:55:37AM -0700, Linus Torvalds wrote:
> Willy, stop this blathering.
> 
> I suspect I will have to just delete this thread unread because it's so 
> full of total crap.
> 
> This whole "working device" argument is total bullshit.
> 
> If the driver was a module before, it needed a module load to become 
> working. If you could load the module, you could load the firmware. Thus 
> the transfer is non-issue.

Sometimes your responses leave me speechless! It's not only a problem of
transfer, but also a problem of selection of what to copy overthere. It
has happened to me more than once when installing a machine to proceed this
way :
  - leave the data center
  - go back to the office to find the driver somewhere
  - burn a CD with it (I once even had to feed it through a 9600 bauds Annex
    port concentrator).
  - go back to the DC and copy it from the CD. I must say that at this stage
    when you see warnings because it's not the exact same kernel version, you
    don't mind anymore and force the load in order to be able to stick an IP
    address on your machine.

Now when you load it and you see it requires a firmware, you're back to #1,
without even the certainty that the firmware you get will :
  a) be the right one
  b) work
  c) be enough
  
So please don't say that the transfer is a non-issue. It is what magnifies
the added complexity.

Instead, I would have loved to see multiboot-compatible module loading.
When your kernel does not support your fresh new RAID card and panics at
boot, you simply put the driver on a floppy (or USB stick), pre-load the
driver from GRUB and boot the kernel. I don't see how this would be possible
anymore with separate firmwares.

Don't get me wrong: I'm not against the ability to separate firmware from
modules, I'm against making that mandatory when it obviously complexifies
a lot of things without any obvious advantage in return.

> Which is just about the same thing as asking people to remember to do 
> "make modules_install" to get a working system. Yes, if you have a driver 
> as a module, you need to install that module for the device to work. Yes, 
> it's definitely "harder", but seriously..

Please don't compare an upgrade of a working desktop or developer machine with
an installation from scratch of a server in an uncomfortable location. Those
are two completely different things.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/