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]

Date:	Thu, 11 Sep 2008 15:25:43 -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 15:07 -0700, Greg KH wrote:
> > And it's a completely bogus example _anyway_, because you're not adding
> > this extra firmware to the kernel tree.
> 
> No, it shows that the firmware does change over time.

For _new_ drivers.

Current drivers.

The ones which would be using request_firmware() anyway.

What is true for those is irrelevant to the discussion at hand. The only
drivers with firmware in the firmware/ directory of the kernel source
tree are the _old_, _unloved_ drivers which don't get updated. If they
had active and competent maintainers, they'd have been switched to
request_firmware() long ago _anyway_.

DIFFERENT DRIVERS, Greg. With DIFFERENT CHARACTERISTICS.

> > 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.
> 
> But it was that "sweep" that has caused problems by having the kernel
> put these files into the lib/firmware directory, without any version
> information unlike any other file that our kernel installs.
>
> That's the only point here.

Yes. Except that it's nonsense because it's not really a problem, unless
you _choose_ to be stupid in the way you package it.

> It seems that the point that it is a bad thing for multiple kernel
> packages to be installing into the same location, no matter if the file
> has the same content or not (date will change which will cause
> problems) isn't coming across here.  Why is that?

Of _course_ it's coming across. So DON'T DO THAT THEN!

Take a look at the Fedora packaging. See how it doesn't do that.

> Think of the very real example here:

 < snip contrived bogus example >

Yeah, that would be broken. Don't do it like that. Or if you _must_ do
it that stupid way, feel free to override INSTALL_FW_PATH. But don't
expect us to pat you on the back for it. It's the _wrong_ thing to do.

> > > > 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.
> 
> It's either use that package or add a patch that upstream seems to be
> objecting to.  That seems a bit "forced".
> 
> > > 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.
> 
> How do you expect anyone to package this up so that no conflicts occur?

Take a look at how Fedora does it. There is a 'kernel-firmware'
subpackage which is automatically generated with the kernel build, but
you don't have multiple such packages installed at the same time -- you
only have the _latest_ one.

This has a theoretical problem if drivers are removed from the tree, or
if firmware is removed from the tree (for example, because a newer
incompatible version supersedes it). That's fixed by packaging firmware
from the linux-firmware.git repository, in which the old firmware will
live on even after the current Linux kernel no longer has it. But since
it _is_ a purely theoretical problem, there's no particular rush for
that to happen. As I said, these ancient unloved drivers aren't getting
their firmware updated _anyway_.

Now, can we _please_ stop being bloody stupid? If there are _real_
problems, like the one I fixed with commit 1cede1af last week, then I'm
perfectly happy to deal with them. But stop making crap up.

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