--- On Tue, 1/20/09, Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote:
> From: Trent Piepho <xyzzy@xxxxxxxxxxxxx>
> Subject: Re: Siano's patches
> To: "Uri Shkolnik" <urishk@xxxxxxxxx>
> Cc: "Mauro Carvalho Chehab" <mchehab@xxxxxxxxxxxxx>, "Michael Krufky" <mkrufky@xxxxxxxxxxx>, linux-media@xxxxxxxxxxxxxxx, "linux-dvb" <linux-dvb@xxxxxxxxxxx>
> Date: Tuesday, January 20, 2009, 3:49 AM
> On Mon, 19 Jan 2009, Uri Shkolnik wrote:
> > Siano has some dozens of commercial Linux-based
> customers using the
> > discussed sources. Those customers have their own QA
> engineers
> > additionally to Siano internal QA team (which includes
> dedicated engineer
> > for this task). Some of those companies products are
> already in the
> > market (production level).
>
> But how much testing do you give other manufacturers'
> hardware with your
> code? Your hardware might work, but you could have broken
> someone else's.
>
> I've found that getting patches into the kernel is
> usually significantly
> harder than writing them in the first place.
mmm.... You have a good point here. I don't know, there is a kind of catch-22 here. True the code may break someone else', or violate something unknown to me. But, how can it be tested if you don't have suitable hardware?
Take the SPI as example. The code is for system with PXA CPU, which is connected with SPI/SPP bus to the SMS DTV chip-set. You need such (hw) device in order to check/test it. Who has this hardware but some manufacturers? Maybe someone bought & hacked such a commercial device, but I never got any indication that anyone did such a thing.
You can of course just compile the code and see if the build is completed successfully, without running it on a real target. This is some kind of code testing, and that is what I referred to as "kernel-coding related remarks" in my post.
Uri
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
