linux-kernel - Re: [git pull] drm request 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Mar 2010 08:21:27 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Ben Skeggs <skeggsb@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...il.com>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Fri, 5 Mar 2010 08:44:07 +0100
Ingo Molnar <mingo@...e.hu> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/