From: Dave A. <ai...@gm...> - 2009-07-20 20:43:37
|
2009/7/21 Thomas Hellström <th...@sh...>: > Stephane Marchesin wrote: >>> >>> You obviously got all this completely wrong. >>> >>> I avoid writing closed source drivers whenever I can, I'm not whining and >>> I'm not trying to push any of them. The code VIA is trying to submit has >>> not >>> been written by me nor anybody I know. All VIA code I and the companies >>> I've >>> worked for has written is open-sourced and contributed to the Openchrome >>> / >>> mesa / drm project. >>> >>> The point I'm trying to make is the following: >>> >>> If the common agreement of the linux community is to *NOT* allow these >>> drivers in, so be it, then be honest and go ahead and tell the driver >>> writers. Don't make them respin their development trying to fix minor >>> flaws >>> when their driver won't get in anyway! >>> >>> >> >> > > Stephane, > Some comments on how these things has been handled / could be handled. >> >> I would like to raise a couple of real-life issues I have in mind: >> >> * First example, let's say VIA gets their Chrome9 DRM merged into the >> kernel. Now let's say I reverse engineer the hardware (or use the docs >> whenever they're available) and write a 3D component that needs >> modifications to the existing DRM interface (or maybe I realize I need >> a completely new DRM). Then who gets the upper hand? Do I have to keep >> compatibility with user space binary modules that I do not care about? >> > > If there is a serious OS project, I'd start a new DRM driver. > That's sort of what may happen with openChrome vs via.. > >> * Second example, what is the policy if we find security holes in the >> DRM for a closed user-space afterwards? This breaks the initial >> promise of security, does that get the driver removed then? Or what if >> the promise is pending updated documentation that never arrives? >> > > I'd say the DRM driver gets disabled unless fixed. How would we handle that > problem today with, for example, the SiS driver? > >> * Third example, what if down the line we need changes in the DRM that >> require updating all DRM modules. Do we (we as in DRM developers) >> touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking >> the code (since we don't test with proprietary modules)? Or do we let >> the Chrome9 files as-is, keeping the old DRM infrastructure and >> therefore add more and more DRM cruft? >> > > Again, this has been done quite commonly in the past and was easier to get > right with the old drm.git testing ground. Same issue with unmaintained > drivers with OS user-space. Who has actually tested all the drivers when > making such a change? I certainly haven't. The change was left for testing > for a while in drm.git before Dave moved it upstream. > >> In my opinion, accepting GPL'ed DRM modules that support binary user >> space components is like opening pandora's box. >> >> Stephane >> > > Yeah, drivers supporting binary blobs only is out of the question as it > seems. > > Now's the tricky question how do we handle VIA's patches where they claim > they have an open-source 2D component that exercises all of the DRM module > for EXA render acceleration, and on top of this the 3D binary driver that > apparently uses no additional DRM functionality compared to the 2D > component? > > In the ideal world I'd of course like to see a Chrome9 3D driver based of > the new openChrome drm driver with a modern GPU memory manager, kernel > modesetting and Gallium, but that's a dedicated man-year or more away if / > when someone decides to work on it. > If VIA releases the DDX code to use the DRM code, and it exercises the ioctls then we can add kernel support for the ioctls the DDX uses. If there a bunch of ioctls specific to the 3D driver we should identify them and see if userspace test code is available. I think this is the same as when poulsbo was proposed, if open code uses the interfaces we add them, if not we don't. I'd also prefer a community approach to work more on the new world order and ignore this interface. Dave. |