modular -> monolithic

[Matthias Hopf]

On Jan 21, 08 12:40:52 +0000, Alan Cox wrote:
> With complex code that is hard to test you need an easy public upstream.
> Three things we learned in the kernel are
> 
> - You need a way for users to install new releases including building
> them which is fairly idiot proof and painless. Not because the users are
> neccessarily idiots but because they are usually busy.
> - You need to get changes to testers outside the core developers fast

With the modularized tree we can e.g. get radeonhd updates out for
testing extremely fast, and people tend to do the upgrade more
willingly, because

- it's less likely to break anything else (read: in the xserver or libs)
- it's easy to go back (just save the one driver file before)
- build time is *much* less than with the monolithic tree.
  This especially holds for drivers, which really compile fast.

> To a great extent internal testing isn't so important. A fast

Most of the time we're not actually talking about testing here, but
about building. Often drivers or subsystems don't even *build* after an
API breakage lately. Having *working* drivers is what we would actually
like to have, but we have to tackle the build problem first. :-(

> change->break->report cyce means you find out what broke fast enough that
> you know what needs fixing and can fix it before it escapes the devel
> candidate trees. If you think about this in terms of information flow,
> feedback loops and system theory it should be obvious.

But please keep in mind that (apparently) working on the kernel is much
more sexy than working on X, otherwise I wouldn't understand why so many
people try out newer kernels, compared to the number of people trying
the current X bits.
Also, if you count the number of developers relative to the code base
size, the kernel has big advantages. I assume this also relates to
attractiveness - and probably to the very open mind of the early kernel
contributers.
When X.org was monolithic, we didn't have more developers. In fact, we
gained quite some by modularization. Because subsystems were easier to
understand, because building subsystems was faster (though building
everything takes longer now), because the internal APIs were somewhat
exposed and better understood.

> X historically (Linux historically at least maybe not JimG historically)
> has had blocks in place to this such as the contributor agreements and
> the difficulty in signing up to the old XFree86 project.

Agreed. Very much.

> I do agree that where the code lives isn't relevant. The Linux kernel
> puts it almost all in one place which makes it easier to do ABI changes
> and to scan for/fix shared bugs. Putting the code in one tree doesn't
> stop it being modular, putting the code in multiple trees doesn't make it
> modular either.

Again, agreed. Even with monolithic build, what most people did was to
only compile those drivers that they were actually interested in -
because a full compile just took too long.
You could do that in the kernel as well, but apparently the mindset is
different, and breaking internal APIs without fixing the code using this
API is considered bad behavior (TM).

I think we're very much missing that mindset in X ATM :-(

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de