On Fri, Nov 29, 2013 at 12:04:04AM +0100, Tomasz Figa wrote: > On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote: > > On Tue, Nov 12, 2013 at 10:35 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: [...] > > > Sorry, this might have been a bit too harsh, but just imagine myself doing > > > my regular patch review round, hoping (as usual) to see only code that is > > > not less than great, while suddenly stumbling upon a line of code that > > > I would expect at most in some vendor tree or maybe several years ago in > > > sources of a 2.4 kernel. > > > > More like code written in the same style as x86 DRM stuff, where > > they're not used to overabstracting things from day one to make things > > generic instead of supporting the only known chip combination to date. > > No, not really. They don't have any modularity on x86. Just a graphics > card with everything on it, so they can freely do such things, as they > don't have to account for all we need to account for on ARM platforms. I don't think there's such a clear difference. A particular GPU on x86 is equally modular as a specific GPU on an ARM SoC. The problem is that on x86 there's much less mix-and-matching going on. So theoretically they do need to account for the same craziness. That's not done, however, because there's no need for it. It doesn't happen in practice. > Also, I wouldn't call making a driver usable and useful for more than > just one fixed platform "overabstracting"... It is if there's never more than the single fixed platform. Since none of us can predict the future I think it's entirely reasonable if we do concentrate on solving the problems that we have now. It doesn't mean that we should write code in a way that makes future enhancements unnecessarily difficult, but I very much prefer to see code merged that supports one specific use-case that we have now rather than working on the code for years on end in an attempt to make it generic enough to support everything that the future can possibly hold. Chances are pretty good that we won't be able to predict one specific use-case and then rewrite everything anyway. Linux has been pretty successful so far in a large part because it has evolved organically. We're not doing ourselves any good by requiring everything to be perfect from the beginning. We all know what a disaster DT has been and still is. It makes it very difficult to get new features supported because we now have a component that we can no longer change at will and that cannot evolve organically anymore. That impedes progress. For this particular issue no DT is involved. There's no need for ABI stability because it's just in-tree code and we can change it to our heart's content. We can refactor things when an actual need arises. By then chances are pretty good we'll have a much better understanding of what exactly we need and therefore we can come up with a much better solution than at this point in time. Thierry
Attachment:
pgporHchc9vwa.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
