Re: [GIT PULL] ViewCast O820E capture support added

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 13, 2012 at 1:36 PM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
> Em 13-08-2012 12:49, Hans Verkuil escreveu:
>> On Mon August 13 2012 16:46:45 Steven Toth wrote:
>>> Hans,
>>>
>>> Thanks for your feedback.
>>>
>>> Oh dear. I don't think you're going to like my response, but I think
>>> we know each other well enough to realize that neither of us are
>>> trying to antagonize or upset either other. We're simply stating our
>>> positions. Please read on.
>>
>> I didn't think you'd like my response either :-)
>
> You probably won't like my answer too, yet I'm also simply
> stating my positions.

Hans / Mauro, thank you for your comments and review, very good
feedback and technical discussion. Truly, thank you. :)

While I don't necessarily agree with Mauro that adoption of subdev is
"MANDATORY" (in the larger sense of the kernel driver development -
and common practices throughout the entire source base), I do hear and
value your comments and concerns from a peer review perspective.

1) A handful of simple improvements have been suggested, Eg.
ioctl_unlocked, double-checking v4l2-compliance, try_fmt, /proc
removal, firmware loading etc

Ack. I have no objections. Items like this are fairly trivial, easy to
address, I can absorb this and provide new patches quickly and easily.
I'll go back over the detailed comments this weekend and prepare
additional patches (and retest).

2) ... and some larger discussion items have been raised, Eg.
Absorbing more of the V4L2 kernel infrastructure into the vc8x0 driver
vs a fairly self-contained driver with very limited opportunities for
future breakage.

Are you really willing to say that all drivers, with unique and new
pieces of silicon, need to be split out into independent modules,
adopting a subdev type interfaces or mainline merge is refused? It's
not that I'm asking you to merge duplicate functionality, duplicate
driver code, replicating functionality for new hardware or for an
existing modules (tuner/demod/whatever). (Like has already happened in
the past - 18271 for example).

If the answer is Yes, then my second questions is:

Assuming the comments / issues mentioned in #1 are addressed, are you
really willing to stand up in front of the world-wide Kernel
development community and justify why a driver that passes user-facing
v4l2-compliance tests, is fairly clean, passes 99% of the reasonable
checkpatch rules, is fully operational, cannot be merged? Really? Is
this truly an illegal or inappropriate driver implementation that
would prohibit mainline merge?

The ViewCast 820 is a (circa) $1800 video capture card. It's not the
kind of hardware that everyone has laying around for regression
testing purposes. If I 1) split this up and people begin to absorb
ad7441 functionality into other designs, and start patching it and 2)
adopt the subdev framework for that matter... then nobody is able to
regression test the impact to the 820. That puts an incredible amount
of burden on me. I'm attempting to mitigate all of this risk, but also
provide a GPL driver so everyone can benefit - without creating a
future maintenance / regression problem, by relying on subsystems the
driver simply doesn't need.

As always, I do welcome and appreciate your comments and thoughts, no
flames from me. I do find the 'MANDATORY' comments worthy of
discussion, or perhaps I've miss-understood something.

Regards,

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux