modular -> monolithic

[Jerome Glisse]

On Mon, 21 Jan 2008 17:25:25 +0100
Luc Verhaegen <libv at skynet.be> wrote:

> On Mon, Jan 21, 2008 at 02:15:18PM +0100, Jerome Glisse wrote:
> > On Mon, 21 Jan 2008 12:33:47 +1000
> > "Dave Airlie" <airlied at gmail.com> 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.
> > 
> > If we ever move back driver maybe we could also take advantage of
> > this to follow kernel way of doing things ie if you change your
> > driver you don't have to check that it will work with old server
> > version but only that it works with the current version of the code.
> > I believe this what happen in kernel: you can't build a 2.6.22 driver
> > code inside a 2.6.0 tree. This would allow to remove old unused
> > code of drivers.
> > 
> > Of course distro won't like this, but hey they are accepting this
> > for the kernel and keeping the burden of backward compatibility in
> > driver is painfull (from my POV and my lazyness).
> 
> It really is not that painful. It just needs the right mindset, as i 
> have been stating all along. And if upstream doesn't make rash changes, 
> it actually is rather easy.
> 
> In any case, the gains of staying backwards compatible seriously 
> outweigh the extra hassle.
> 
> Luc Verhaegen.
> SUSE/Novell X Driver Developer.

Well to my point of view main advantage of having driver tree in
sync with master tree is that you can just remove old unused code
and for video driver this would let you delete all old mode setting
code as we now mostly use interface introduced along randr 1.2.
I see it as a win and as Alan pointed out if distrib want to backport
than it's their problem !

So i truely don't see a win in being backward compatible except making
easier for people to test but hey tester in kernel build their whole
kernel... And truely i can see how to outweigh the possibility to throw
interface and change them when appropriate without having to add tons
of ifdef in the driver code just for staying backward compatible with
old api which didn't let you do things you need (assumption being that api
change are motivated by somethings :))

Cheers,
Jerome Glisse