netdev - Re: [bug?] tg3: Failed to load firmware "tigon/tg3

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:	Sun, 06 Jul 2008 19:40:55 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, tytso@....edu,
	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"

Alan Cox wrote:
> On Fri, 04 Jul 2008 10:07:23 -0400
> Jeff Garzik <jeff@...zik.org> wrote:
> 
>> David Woodhouse wrote:
>>> On Fri, 2008-07-04 at 09:39 -0400, Jeff Garzik wrote:
>>>> You have been told repeatedly that cp(1) and scp(1) are commonly used
>>>> to transport the module David and I care about -- tg3.  It's been a
>>>> single file module since birth, and people take advantage of that
>>>> fact.
>>> And you can _continue_ to do that. You'd need to install the firmware
>>> just once, and that's all. It's a non-issue, and it isn't _worth_ the
>>> added complexity of building the firmware into the module.
>> We can stop there.  Real-world examples are apparently non-issues not 
>> worth your time.
> 
> Jeff - real world issues and gains are measured on a scale across the
> userbase not "Jeff's having a tantrum because his specific usage case
> requires one extra copy once"

Please look at the example as an example of an entire _class_ of usage 
that dwmw2 wishes to hand-wave away.

There are many cases where you have the freedom to update the module, 
but not the kernel itself -- see vendor kernels and driver update disks, 
or the typical usage of the upstream kernel's out-of-tree-module build 
support.

It is trivial to think for five minutes and come up with other examples, 
because the simple fact is, there is a failure to follow a basic 
principle of kernel development:  no regressions.

All I'm asking for: what works today, should continue to work tomorrow.

Why is that so wrong?

We applied that principle with libata -- if you did not turn it on, you 
didn't even have to know it was there.

We applied that principle with kernel modules -- if you do not turn them 
on, you have the static kernel you've always had.

> And we had the same argument over ten years ago about those evil module
> things which stopped you just using scp to copy the kernel in one go.
> Fortunately the nay sayers lost so we have modules.

Broken analogy.

When modules were added, you were given the option to use them, or not.

dwmw2's conversion is not providing analogous choices.

	Jeff

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