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, 6 Jul 2008 10:29:48 -0400
From:	"Devin Heitmueller" <devin.heitmueller@...il.com>
To:	"David Woodhouse" <dwmw2@...radead.org>
Cc:	"Klaus Schmidinger" <Klaus.Schmidinger@...soft.de>,
	kernelnewbies <kernelnewbies@...linux.org>,
	kernel-janitors <kernel-janitors@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Jaswinder Singh" <jaswinder@...radead.org>, linux-dvb@...uxtv.org,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-dvb] [PATCH] Remove fdump tool for av7110 firmware

On Sun, Jul 6, 2008 at 7:17 AM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Sun, 2008-07-06 at 11:09 +0200, Klaus Schmidinger wrote:
>> On 07/06/08 03:15, Oliver Endriss wrote:
>> > Jaswinder Singh wrote:
>> >> There's no point in this, since the user can use the BUILTIN_FIRMWARE
>> >> option to include arbitrary firmware files directly in the kernel image.
>> >
>> > NAK! This option allows to compile the firmware into the _driver_,
>> > which is very useful if you want to test various driver/firmware
>> > combinations. Having the firmware in the _kernel_ does not help!
>>
>> I strongly support Oliver's request!
>> Working with various driver versions is much easier with the
>> firmware compiled into the driver!
>
> That's strange; I've found exactly the opposite to be the case.
>
> If I want to test permutations of driver and firmware, as I've done for
> the libertas driver a number of times, I find it _much_ better to
> preserve the modularity. I can build each version of the driver and can
> test that against various firmware versions without having to rebuild
> it, and with much less chance of something going wrong so that I'm not
> actually testing what I think I'm testing.
>
> Perhaps I'm missing something that would help me work better? Please
> could you help me understand how you currently work, and I'll attempt to
> make it easier for you. Can you talk me through an example of a session
> where you had to do this testing of 'various driver/firmware
> combinations'?
>
>
> --
> dwmw2
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@...uxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

Correct me if I'm wrong, but doesn't this also affect those
distributions that consider kernels with binary firmware blobs to not
be free software?  Those distributions take the stance that the
firmware must be loadable by userland, in which case the proposed
patch removes this capability.

Is there some downside to leaving this functionality in there?  Are
there known bugs or maintainability issues with the code as-is?

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ