modular -> monolithic

[Luc Verhaegen]

On Mon, Jan 21, 2008 at 12:33:47PM +1000, Dave Airlie wrote:
> On Jan 21, 2008 10:47 AM, George Michaelson <ggm at pobox.com> wrote:
> > I have really only twiddled with Xorg as an early-adopter (l)user,
> > hassling developers. But I have looked at and built code
> > off GIT as well as packaged state.
> >
> > I believe that the cost to the BSD camp in terms of re-factoring their
> > packaging model to take account of modular server build, and
> > disaggregated drivers has now been 'amortized' (for want of a better
> > word) and the benefits are coming in.
> >
> > I can't speak for other distributions/OS but I suspect the same is
> > true. 1-2 years of painful integration is now either complete
> > or nearly so. A litany of documentation and supporting activity is now
> > built around things as they are.
> >
> > To take the step of walking backwards into monolithic build, at this
> > point, would make quite a lot of people in your userbase very unhappy
> > (I believe). Do you really want to "just do it" this time? RIght now?
> 
> The thing is modularity was about a whole lot more than
> server/drivers, it was primarily about removing the libs fonts and
> apps and Mesa builds from the server build, granted the drivers were
> done at the time but this may have been a step too far, I can't see
> rolling the drivers back into the server package being a major job for
> any distro.. the big thing of going to modular for distros was
> autotools and depend tree building..
> 
> Dave.

This whole "partial" remonolithicalisation seems to not address the real 
issue, which is a wrong general mindset, and instead this equals 
sticking ones head in the sand and hoping that things magically go 
away.

There is no advantage to this as opposed to having a build test system 
placing blame all the time. Each choice incurs pain, but one choice has 
only pain and no undesired (or desired) sideeffects.

But i think there are some things you are working towards that you 
aren't immediately telling us. Things which would be rather hard to 
stomach, unless it gets sneaked up on all of us.

By moving drivers inside the tree again, a load of drivers will get 
culled, right? And then the new monolith can be blamed for that.

The other "advantage" is that you can let the SDK bitrot and then 
eventually kill that too.

So, you would be using the new monolith as an excuse to drop those 
things you probably (wrongly) see as a "limiting factor" to development.

Now...

Remonolithicalisation will not solve the real issue, it will only 
exacerbate it.

There will probably be a major cull. After which, rm -Rf will be the 
standard way of dealing with no-longer-building drivers, that is, when 
they are not one of the Big Three. Heck, i'm sure some people here would 
prefer to cull all but the Big One.

Then there is the fact that drivers are not supposed to build outside of 
the server any more, and are no longer made backwards, means that users 
have to spend all their time compiling X servers. This to test bugfixes 
for their drivers or to get the hardware support they need.

This does not exactly speed up driver development.

And this does not in any way change the problem of building a new X 
stack from nothing.

Not many people in this whole discussion have really built X themselves 
recently. I know i haven't done so for the last year or so, even though 
i should. It is just too big a hassle.

Now, for me and for people who actually want to use X, building the 
drivers is not the problem at all. They usually only have a limited 
amount of dependencies. Xserver, libdrm, and that's pretty much it.
This is because building the drivers is easy once you have an Xserver.

Building the Xserver isn't, and this is why the various build scripts 
and tools have existed, or why people generally have stopped building X.

So, joining Xserver and drivers has no advantage there.

All you will end up doing is slowing driver development.

Everybody agrees we need improved build breakage checking, and some way 
of placing blame, so that people are not dragging their feet as much 
on fixing drivers, or so that people make more carefull decisions 
concerning api changes.

And while you might not like it, a tinderbox like system will not lead 
to a wholesale driver cull, or subsequent culling of the SDK.

Luc Verhaegen.
SUSE/Novell X Driver Developer.