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]

Date:	Thu, 17 Jul 2008 00:05:03 +0200
From:	Diego Calleja <diegocalleja@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Frans Pop <elendil@...net.nl>, arjan@...radead.org,
	akpm@...ux-foundation.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.

El Tue, 15 Jul 2008 16:26:41 -0400, Jeff Garzik <jeff@...zik.org> escribió:

> And yes, it enables "weirdos" like me to continue building the firmware 
> into the driver, because it has a proven track record of high 
> reliability and simplicity.

I'm one of those "weirdos", and I'd like to explain from my user-POV (a user
who usually compiles and tests -rcs) why I prefer firmware-in-module I don't
find it "weird".

I use modules as much as I can. Apparently many people here uses non-modular
.configs. Me, I learnt lot of time ago that we live in a hotplugged world
were you can't predict what hardware you are going to need to plug, and you
don't want to tell your girlfriend that you need to compile a "kernel module"
because she brought a USB memory stick and you didn't compiled the support
when you compiled your kernel. And I don't like doing "lspci" every time I
want to know what network card I have in a box. So I compile everything as
a module (except the support for all sata/ide controllers and ext3, to
avoid the nightmares of initrds) and I let udev do all the job. I only use
external firmware when it's strictly needed for legal reasons.

Yes, just like I can do "make modules_install", I can do "make
firmware_install". It's not hard - just an extra command. But it's an
extra one. And I'm lazy to the point that I'm _not_ willing to type
that extra command. You could install the firmware automatically with
"make modules_install". Still, I'd need to cleanup frequently
/lib/firmware/<version> because of all the crap (and MB) that old
-rcs and -next's versions will leave there.

Those are _extra_ steps. Steps that force me to learn things that
I didn't need to know before. I didn't even know if my network
card had firmware or not. I never cared, and I don't want to start
caring about it now.

With firmware-in-module, I can switch a simple config option that will
get me back to my ignorance of firmware related things. And Jeff will
be my hero of the month for bringing back the simplicity of the old
times, while the rest of the people that want to force me to learn about
firmware (iow, the people who thinks that firmware-in-module is worthless)
remember me of the microkernel people, who could write books and give
speeches in universities about how insanely great is to have fulfilled
one of the most important problems in the story of CS - separating
firmware from the driver code. Despite of the fact that it does not
bring ANYTHING new for me, excepting added complexity.

I'll continue using external firmware only when for legal reasons it
can't be redistributed, of course, but fortunately for me that's an
exception on my hardware devices, not the rule.
--
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/