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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Sep 2008 10:36:46 -0400
From:	Jeff Mahoney <jeffm@...e.com>
To:	Theodore Tso <tytso@....edu>, Jeff Mahoney <jeffm@...e.com>,
	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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Theodore Tso wrote:
> On Thu, Sep 11, 2008 at 03:15:12AM -0400, Jeff Mahoney wrote:
>> 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.

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.

Driver maintainers need to worry about remembering to up the version
every time the firmware blob changes. If the blobs are always kept with
the associated kernel version, then it's fire and forget, the same way
internal API changes are.

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.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjJLP4ACgkQLPWxlyuTD7I5aQCbBRYn5wv3GbLw1cxUsDr/PxuC
ml0An2WjJwkYEz4hQadUi0PosZe6n6ng
=rY53
-----END PGP SIGNATURE-----
--
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/