modular -> monolithic
Bernardo Innocenti
bernie at codewiz.org
Sun Jan 20 11:20:34 PST 2008
To summarize, it seems there's interest in merging the
drivers back into the server tree.
However, I see a few downsides that need solving before
we can say it can be done:
1) build time and build complexity
The Linux kernel can afford to ship thousands of drivers
thanks to the very fine-grained Kconfig infrastructure,
so that developers don't necessarily need to pay the full
price of a big rebuild every so often.
Autoconf is clearly not up to solve this issue.
My configure command line for the xserver already spans
5 lines and one can't paste it on IRC without being kicked
from the channel.
Switching to Kbuild also doesn't seem like a bright idea,
because unlike the kernel we *need* to run autoconf tests
for portability.
I don't know enough about cmake to comment on it, but
switching to a totally different build system would be a
huge amount of work that I guess nobody would be willing
to do.
2) packaging
Distributions are very likely to prefer packaging drivers
separately from the server. Especially on embedded
platforms, this can be very important.
Not a big issue, but we'll receive some interesting hate
mail from downstream packagers for moving things around
once again when some distributions are still migrating to
the modular layout :-)
3) spreading the development burden
Some refactorings are deemed to break the driver API.
We've seen it with the pci-rework and the input changes.
While it seems logical that whoever broke things ought to work
on fixing them, I see it as a *huge* drag on development if
we impose a perfectionist policy that discourages any big
change.
Remember the story of the broken Iomega Zip driver in
Linux 2.6.0? Some people wanted called for delaying the
release indefinitely to fix this "regression". Others
wanted to revert the patches that broke it. Linus had
this interesting position that if nobody cared to send
a patch in months, he could not care less about the
Iomega Zip because he did not even have one!
{{citation needed}}
Xorg has an impressive heritage of severely bitrotting
hardware drivers. And the reason few people care to fix
them simply reflects the fact that few people actually
*use* that hardware! Letting the old cruft slowly bitrot
and die based on how much love they spontaneously attract
is a nice and natural way of evolving any large codebase.
So what I'm suggesting here is that whoever is willing to
rework the core server takes *reasonable* steps to fix the
major driver regressions, possibly in collaboration with
the driver maintainers.
Unless we settle (1), (2) and (3) in a satisfactory way,
my $0.02 opinion is that merging the drivers back would
cause more struggle than the advantages we all see.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
More information about the xorg
mailing list