linux-kernel - Re: [PATCH] firmware: Allow release-specific firmware dir

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: <1221167725.4077.34.camel@macbook.infradead.org>
Date:	Thu, 11 Sep 2008 14:15:25 -0700
From:	David Woodhouse <dwmw2@...radead.org>
To:	Greg KH <greg@...ah.com>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Thierry Vignaud <tvignaud@...driva.com>,
	David Miller <davem@...emloft.net>, jeffm@...e.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

On Thu, 2008-09-11 at 13:57 -0700, Greg KH wrote:
> On Thu, Sep 11, 2008 at 01:38:38PM -0700, David Woodhouse wrote:
> > On Thu, 2008-09-11 at 13:15 -0700, Greg KH wrote:
> > > This is the firmware that is in the kernel source tree, that has been
> > > moved to use request_firmware, and was originally tied tightly to the
> > > kernel drivers themselves.
> > 
> > Not really. Most of it hasn't changed for years; it isn't _really_ tied
> > that closely to the kernel. 
> 
> Some are and some aren't (I have two in my -staging tree that are
> changing as the driver changes, so it does happen.)

That's fine. Just make sure the filename changes when an incompatible
change is made to the firmware -- just like you handle sonames in
libraries. It's not hard, and you should _always_ have been doing it.

And it's a completely bogus example _anyway_, because you're not adding
this extra firmware to the kernel tree.

Remember, all recent drivers have been using request_firmware() for
years anyway, and even the older drivers with active and on-the-ball
maintainers have been switching to request_firmware().

All I've done _recently_ is a bit of a sweep on the stragglers. And
because of the amount of stupid whining, I made it possible to keep it
in the kernel tree rather than just evicting it, as we did in the past.

> > You can just ignore what the kernel ships with, and install the firmware
> > from the linux-firmware.git repository instead.
> 
> So you are now forcing distros to ship the linux-firmware.git repo
> instead?  That's not nice and is a totally new dependancy for them to
> handle.

Not at all; that's the ideal situation, but nobody's forced to do it
that way.

> What about the very basic fact that kernel versions will stomp on files
> from other kernel versions if you install multiple kernels on the same
> machine?  That's just bad and ripe for problems in any package
> management system.

Only if you do stupid things in your packaging. So don't do that.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
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/