Daniel,
On 04/05/2011 05:51 PM, ext Daniel Stone wrote:
On Tue, Apr 05, 2011 at 04:30:38PM +0300, Tiago Vignatti wrote:
But my point is (well, always was) to chop off the server internal
modules in parts so we can have a lean implementation for different
purposes and cover everyone's desires. The testing and conformance
could be stressed in a different way, but not just compiling and
forcing developers to use the thing.
Sure, but at some stage there has to be a limit. Every configuration
option has a cost: in making the source files larger by putting #ifdefs
everywhere - and you could argue we already have enough of those, by
implementing the alternate codepath, by testing that both codepaths
build, by testing that both codepaths work, by documenting it, by
supporting users who use it, etc, etc. The server is not exactly a
simple place as is, so adding additional complexity should be carefully
considered[0].
So, if there's a demonstratable benefit, then cool! By all means. But
if we're doing it either just for the sake of it, or to provide an
absolutely trivial savings in binary size which could be much better
accomplished elsewhere[1], then I don't see that the tradeoff makes
sense. Even so, is the result really usable? No-one using relative
devices wants no acceleration.
it's not about binary size, nor memory savings. They are not the main
benefits we should be targeting when talking about the server
modularization - or did you care about it as a motivation for xkbcommon?
It's about organization of the code really, which leads to correct
driver API usage, so we could talk about deprecation and proper
versioning of unused/old/unmaintained drivers - we would be enforcing
ourselves to use correct interfaces. Privately. So, I'm sure if we pick
90% of the code inside Xorg DDX we will see that they are used only for
old drivers. IOW, why a newer server needs to support a very old driver?
Tiago
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
