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: <20080715050654.GH1369@1wt.eu>
Date:	Tue, 15 Jul 2008 07:06:54 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Woodhouse <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 Mon, Jul 14, 2008 at 08:29:13PM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 14 Jul 2008, Jeff Garzik wrote:
> > 
> > Do you really think embedded system and micro distro authors are in 100%
> > agreement that /lib/firmware is best for their situation?  Really?
> 
> Umm. Why are you bringing up these total red herrings?

It's not red herring, Linus. I (as a user, as an embedded system developer
and as a micro distro maintainer) do really care.

> Those embedded systems can just build everything into one image, and are 
> much better off using no modules at all.

While it is sometimes acceptable to have everything built into one image,
sometimes your embedded system is modular in that the same image works
on several hardware variants. In this case, it's largely preferable to
work with modules.

> But how about instead of complaining, help add the infrastructure then, so 
> that you can insert those firmware things into modules and still use just 
> one single interface? 

I think that would make everyone happy. It would be worth taking a
look at myri10ge version 1.4.2 to see how they managed to support
both mechanisms.

> Move _forward_, not backwards.

This is just a matter of point of view. From my POV, having to feed
several unrelated files into a system to be able to get it to support
any device is moving backwards, compared to the currently clean all-in-1
driver model.

BTW, I still did not understand what existing problem we are trying
to solve by this move "forward".

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/