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:	Sat, 05 Jul 2008 13:22:20 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Olivier Galibert <galibert@...ox.com>,
	Takashi Iwai <tiwai@...e.de>,
	David Woodhouse <dwmw2@...radead.org>,
	Hannes Reinecke <hare@...e.de>, Theodore Tso <tytso@....edu>,
	Jeff Garzik <jeff@...zik.org>,
	Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, hugh@...itas.com,
	akpm@...ux-foundation.org, kosaki.motohiro@...fujitsu.com,
	mchan@...adcom.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

Olivier Galibert wrote:
> On Sat, Jul 05, 2008 at 09:41:56AM +0200, Takashi Iwai wrote:
>> Yes, it will, if the firmware blobs are packed into the kernel
>> package.  In a long term, we can put firmware files into a separate, 
>> architecture independent noarch package, though.  This will save the
>> total package size, too.
> 
> That could be interestingly hard, actually.  Right now the kernel
> package is one of these packages designed so that multiple versions
> can be installed together.  When the version of one of the firmwares
> changes, the firmware package will have to be updated.  But will it
> keep the previous version?  If it doesn't, the possibly still
> installed older kernels won't work anymore.  If it does, it will
> accumulate a lot of files over time...

Many distribution have some way for separate kernel module packages.
It's essentially the same problem so it should be already solved
in some way. Also there are already drivers who rely on separate
firmware so they already should have this problem (and hopefully
a solution). Of course these existing solutions might not be good
enough. And a lot of people ignored them because they didn't use
these external packages and drivers with those requirements.

I agree with you that doing this for more drivers will be a further complication
and the rationale why this complication is needed for drivers like tg3 or
e100 so far didn't  sound very convincing to me. If I read it correctly it
was "some other drivers do it this way so let's complicate everybody and
put them on the same level". Perhaps I'm dense, but I failed
to see the convincing reason in that.

On the other hand for my personal use it this change should be
transparent, at least as long as "make firmware_install"
will be integrated into "make modules_install" and put the files somewhere where
they don't conflict with other versions.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ