From: Oliver Endriss <o.endriss@gmx.de>
Organization: ESCAPE GmbH EDV-Loesungen
To: linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] [PATCH] Remove fdump tool for av7110 firmware
Date: Mon, 7 Jul 2008 04:52:00 +0200
User-Agent: KMail/1.9.6
Cc: David Woodhouse <dwmw2@infradead.org>,
       Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>,
       kernelnewbies <kernelnewbies@nl.linux.org>,
       kernel-janitors <kernel-janitors@vger.kernel.org>,
       LKML <linux-kernel@vger.kernel.org>,
       Jaswinder Singh <jaswinder@infradead.org>,
       Alan Cox <alan@lxorguk.ukuu.org.uk>
References: <1214139259.2994.8.camel@jaswinder.satnam> <48708BBF.9050400@cadsoft.de> <1215343022.10393.945.camel@pmac.infradead.org>
In-Reply-To: <1215343022.10393.945.camel@pmac.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200807070452.02204@orion.escape-edv.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2429
Lines: 56

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/