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: <1221150558.6309.50.camel@californication>
Date:	Thu, 11 Sep 2008 18:29:18 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	Jeff Mahoney <jeffm@...e.com>
Cc:	Theodore Tso <tytso@....edu>,
	Faidon Liambotis <paravoid@...ian.org>,
	David Miller <davem@...emloft.net>, dwmw2@...radead.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

Hi Jeff,

> >> In the end, though, Andrew's right. We can't go breaking udev prior to
> >> 127 with this.
> > 
> > But it's OK to break various distribution's kernel packaging tools?
> 
> No. I still think the right answer is to keep them in a versioned
> directory and I'm keeping this patch applied to the SUSE kernel trees.
> Udev in the next release understands where to look. It's just clear that
> there's some disagreement if that's the right answer for everyone. My
> opinion is that if the firmware blobs are built with and shipped with
> the kernel, then they're already associated with a particular kernel
> version as a dependency the same way we'd treat module dependencies.

no they don't depend on a kernel version. The firmware depends on a
specific driver version (and hardware in some cases). The kernel version
is totally irrelevant in this case.

> It's silly to willfully complicate the situation beyond just including
> the firmware blobs with the kernel. Even though it sounds a lot simpler
> to just say, "keep a separate firmware package," the reality is that it
> creates more work for everyone, developers, users, and packagers alike.
> I recently updated the kernel on my notebook to a 2.6.27-rc, only to
> find out that the firmware blob that I already had installed was out of
> date and the driver was useless without it. This is an example of an
> externally-maintained firmware blob, but creating a separate package out
> of firmware blobs essentially makes all of them externally maintained
> and forces in-kernel developers to jump through the same hoops that
> third-party driver maintainers must.
> 
> Packagers will need to keep track of every firmware version associated
> with every kernel, since users may want to install multiple kernel
> versions. This is the entire point of the thread, and it assumes that
> the user installing the kernel is even using a packaged kernel. If
> they've just built their own and have done a make modules_install ; make
> install, then they're out of luck.

We do have MODULE_FIRMWARE for that.

> Putting them in their own directory just makes it obvious and easy for
> everyone. The issue is that firmware.sh isn't looking there right now.
> Perhaps making optional symlinks is the answer.

Making symlinks is just a workaround. It will not solve anything in the
long term.

Getting all the firmware out of the kernel and getting it into a
separate package is the solution. And to avoid any breakage or problems
the firmware files itself have to be versioned. Firmware like every
other software has its version numbers already. It is like any other API
and once you break it in an incompatible why, you should increase the
major version number. The kernel version has nothing to do with it.

Regards

Marcel


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