linux-kernel - Re: [linux-dvb] [PATCH] Remove fdump tool for av7110 firmware

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:	Mon, 7 Jul 2008 04:52:00 +0200
From:	Oliver Endriss <o.endriss@....de>
To:	linux-dvb@...uxtv.org
Cc:	David Woodhouse <dwmw2@...radead.org>,
	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>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-dvb] [PATCH] Remove fdump tool for av7110 firmware

David Woodhouse 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'?

Note that the v4ldvb drivers can be configured and compiled outside the
kernel tree. Basically I have several directory trees, for example
- v4l-dvb_head
- v4l-dvb_31dec2007_fw2622
- v4l-dvb_31dec2007_fwf12623
- ...

Within these directories you can simply use "make menuconfig" to
configure the driver. If you compile the firmware into the driver,
you can easily freeze a 'known good' or 'known bad' configuration.

Trying a different driver is as easy as changing directories.
This simplifies testing.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------
--
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/