modular -> monolithic

[Bernardo Innocenti]

Matthieu Herrb wrote:

> This has of course some constraints. The more proeminent one is that
> care should be taken to keep the interfaces between the X server and the
> drivers as stable as possible, and to provide some level of backward
> compatibility when this interface changes.

I agree on the necessity to keep the interface clean, for
software engineering reasons.  I don't necessarily agree on
the need to keep the ABI/API stable whenever we find
interesting improvements with a good cost-to-benefits ratio.


> This rule has been violated too often in the past hurting all 3rd party
>  module maintainers. But with ajax's work to clean up the interface, we
> should be able to do less mistakes like this from now.

AFAIK, most off-tree modules are finally migrating back to
being hosted on f.d.o., so it doesn't seem like a major
concern any more.

Also AFAIK, there are just 2 major proprietary drivers left,
with one of them being rapidly replaced in functionality and
performance by its open-source equivalent, and the other one
making promising steps forward.

I don't see the number of proprietary drivers going up in
the future, and I can certainly bet it will tend to go down
now that there's just one renitent hardware vendor being
left alone in their strategy of secrecy reminiscent of the
cold war ;-)


> Last point, one of the goals of the modularization effort was to make it
> possible to contribute to X.Org without having to build the whole tree.
> This is one very important one. Too many people struggle to build the
> whole X.Org without a real need for it. But without stable interfaces,
> it will never be possible to do any development on a system that is not
> shipping bleeding edge versions of all packages.

This is an important point.  Linux lets you build the kernel
proper without modules and even a single module, although
it's a bit too arcane for users to benefit.

We'd certainly benefit if one could just cd to a module
subdirectory and run make there.  As long as you accept
to configure the whole tree, the automake recursive makefiles
support this use case quite well.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/