2009/7/20 Thomas Hellström <tho...@shipmail.org>: > > 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.. >
Well, for user space, there can be as many drivers as you want for a given device. But the DRM policy always was one driver per hardware so as to avoid confusing people, so what you're proposing is in fact not possible. In that case, this would even deter a fully open source driver as it would have to keep the same interface as some (possibly unsupported) driver. >> * 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? If no one can fix it it gets killed, yes. I would expect this to happen pretty quickly in fact, in which case the "driver merge/problem found/driver removal" cycle requires more work than it's worth. > >> * 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. > Well, some of us want to be thorough when doing invasive changes, untestable code would prevent such changes (and then we get more of the DRM cruft as a result). And yes, if people do not cooperate on all drivers, this leads to issues in the code. At this point it's not a matter of open source vs closed, but a problem of cooperation. Stephane ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
