Re: [PATCH 1/4] introduce intel_ring_buffer structure

[Simon Farnsworth <simon.farnsworth@onelan.com>]

On Tuesday 18 May 2010, "Zou, Nanhai" <nanhai.zou@intel.com> wrote:
> >>-----Original Message-----
> >>From: Daniel Vetter [mailto:daniel@ffwll.ch]
> >>Sent: 2010年5月18日 1:43
> >>Well, that's exactly the problem. You simply can't optimize a kernel
> >>interface once it's in use. And if you try to, your users will get the
> >>pitchforks and scream bloody murder trying to get you ;) So we need to
> >>get these patches right (at least the semantics of the interface)
> >>beforehand.
> >>
> Hi,
> Since VAAPI will be the only client for this multi ring buffer for a period
> of time. We may not have so much pain to optimize both kernel and user
> space. This approach touches little user space interface, only 1 new  flag
>  is added to IOCTL. We have new kinds of ring buffer to come in
> SandyBridge and later chips. Since we are still enabling  SandyBridge. I
> can not for cast how those rings would be synchronized to each other. We
> may use minimum API to work first.
> 
Be aware that you cannot expect users to bump both their userspace VAAPI 
library and their kernel at the same time; there are good reasons for this.

If you do tie the VAAPI library version and the kernel version too tightly 
together, you get into a position where users get upset - if I bump my kernel 
from 2.6.32 to 2.6.36 to get support for a new WiFi chipset and a new TV 
capture card, I'm likely to get quite upset if I then have to also respin my 
userspace.

There are also issues around bisection as a tool for isolating regressions - 
if I have to carefully bump userspace and kernel in lock-step, it's very 
difficult for me to bisect down until I find the changeset that broke things. As 
most of the bugs you'll get reported from users like me won't reproduce in 
your lab, making it harder for me to give you helpful information is not in 
your interests.

In conclusion, as Daniel's been saying, you must get the kernel interface 
mostly right first time. If it's too slow, a new interface to improve 
performance isn't hard to add in parallel to the old interface; if the old 
interface is a DoS vector or worse, you're going to get stuck in a very bad 
place.
-- 
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx