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