Re: [git pull] drm request 3

From: Jesse Barnes
Date: Fri Mar 05 2010 - 11:21:19 EST


On Fri, 5 Mar 2010 08:44:07 +0100
Ingo Molnar <mingo@xxxxxxx> wrote:
> It's a bit as if we split up the kernel into 'microkernel' components, did a
> VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and
> then tried to develop them as separate components.
>
> If we did then then Linux kernel development would slow down massively while
> in reality everyone would _still_ have to have the latest and greatest source
> checked out to do some real development work and to be able to implement
> features that affect the whole kernel ...
>
> Linux would become an epic fail of historic proportions if we ever did that.

This is a very good point, and something we've been wrestling with in
the gfx community. Awhile back we separated the X drivers from the X
core; I feel this was a mistake for the reasons you mention above.
It's just plain harder to fix issues when you have to rev the ABI with
every change, make sure both the old/new and new/old combinations work,
and generally improve things like we do inside of Linux.

> [*] I realize that it's possibly hard for Xorg to merge with mesa and the
> kernel for license reasons, but my technical observation still stands.

No we don't need to merge them fortunately. With GEM and KMS we've
pushed two major bits of functionality into the kernel; bits that were
badly split between all portions of the stack before. With EGL, we can
push a lot of what X did into Mesa. There are even some projects to
make a very thin X driver or separate display server sit directly on
top of Mesa + EGL, unifying things further. So I really think things
are getting better here, not worse (the nouveau issue here aside).

--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/