From: Ingo Molnar <mingo@elte.hu>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ben Skeggs <skeggsb@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Dave Airlie <airlied@gmail.com>, Dave Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org,
Jesse Barnes <jbarnes@virtuousgeek.org>,
dri-devel@lists.sf.net
Subject: Re: [git pull] drm request 3
Date: Fri, 5 Mar 2010 08:44:07 +0100 [thread overview]
Message-ID: <20100305074407.GC19703@elte.hu> (raw)
In-Reply-To: <84144f021003042306w2e017efbva2be364c1c4980a7@mail.gmail.com>
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > The conclusion is crystal clear, breaking an ABI via a "flag day"
> > cleanup/feature/etc is:
> >
> > ?- wrong
> >
> > ?- harmful
> >
> > ?- limits the developer base
> >
> > ?- limits the tester base
> >
> > ?- wastes time and effort. (fewer developers/testers means that while _this_
> > ? feature was easier to add, all your _future_ features will be a bit harder
> > ? to do. It compounds up.)
> >
> > ?- so it hurts even the very developer who is most convinced that this was the
> > ? right thing to do
> >
> > It's a bad technical decision throughout. It's masochistic and often suicidal
> > to just about any project in essence. I've seen projects that did it once and
> > died just due to that single act of stupidity. I've seen projects that have
> > done it a few times and took the usage hit, limped along with the wounds and
> > never grew to the size they could have achieved. I've seen projects that did
> > it once, took the hit, learned from it and never did it again.
>
> Agreed. What bothers me in this discussion is that people keep bringing up
> the fact that nouveau is mostly developed by volunteers and thus it doesn't
> make sense to make sure it's backwards (or forwards) compatible. But the way
> I see it, it's the complete opposite. It's _more_ important to support ABIs
> for community-driven efforts because you're relying on people who by
> definition don't have time to waste. While the nouveau people might have
> good intentions, I'm afraid they might be severely limiting their developer
> and tester base because they're not focused on real world problems (like the
> ones Linus is seeing).
Yeah. I've seen a few other bad arguments as well:
'exploding test matrix'
This is often the result of _another_ bad technical decision:
over-modularization.
Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:
- it's developed by the same tightly knit developer base who often cross
between these packages. Features often need changes in each component.
- a developer to be able to do real work has to have the latest sources
of all these components.
- a user just uses whatever horizontal version cut the distro did and never
truly 'mixes' these components as a conscious decision.
- distros just try to get the latest and most capable but still stable
version. Desperately so. Often they will create a version mix that was
never tested by developers in that form. They'll expose users to ABI
combinations that were never really intended. They have trouble
bootstrapping and stabilizing those essentially random combinations and
then have trouble applying stability and security fixes.
The thing is, if development has such characteristics then it's pretty clearly
not 3-4 separate projects but _one_ abstract project. [*]
So the 'exploding test matrix' is simply the result of: creating ABIs between
3-4 _artificial components of the same project_ and then going through
developer hell living with that mistake. [**]
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.
Ingo
[*] 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.
[**] I realize that modularization and many small packages were a clear
advantage when we were still all downloading bits via 14.4k modems, but
in this day and age of megabit connections that has become a non-issue.
Rampant over-modularization and the resulting loss of focus on the end
result (and the resulting explosion of a test matrix) is hurting us _far
more_ than the disadvantages of any monolithic could ever hurt. We are
seeing the proof of that all day with a 10+ MLOC kernel.
next prev parent reply other threads:[~2010-03-05 7:44 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 23:56 [git pull] drm request 3 Dave Airlie
2010-03-04 18:18 ` Linus Torvalds
2010-03-04 18:27 ` Matt Turner
2010-03-04 18:36 ` Jesse Barnes
2010-03-04 18:39 ` Jesse Barnes
2010-03-04 18:51 ` Linus Torvalds
2010-03-04 18:56 ` Jesse Barnes
2010-03-04 19:08 ` Linus Torvalds
2010-03-04 19:25 ` Dave Airlie
2010-03-04 20:01 ` Linus Torvalds
2010-03-04 22:06 ` Dave Airlie
2010-03-05 0:08 ` Linus Torvalds
2010-03-05 0:28 ` Ben Skeggs
2010-03-05 0:41 ` Linus Torvalds
2010-03-05 0:56 ` Luc Verhaegen
2010-03-05 1:08 ` Linus Torvalds
2010-03-05 1:16 ` Luc Verhaegen
2010-03-05 1:22 ` Linus Torvalds
2010-03-05 1:20 ` Linus Torvalds
2010-03-05 1:28 ` Dave Airlie
2010-03-05 5:17 ` Linus Torvalds
2010-03-05 5:22 ` Dave Airlie
2010-03-05 5:30 ` Linus Torvalds
2010-03-05 5:42 ` Linus Torvalds
2010-03-05 1:19 ` Upstream first policy Kyle McMartin
2010-03-05 1:28 ` Linus Torvalds
2010-03-05 2:00 ` [git pull] drm request 3 Tony Luck
2010-03-05 20:34 ` Felipe Contreras
2010-03-05 6:49 ` Ingo Molnar
2010-03-05 7:06 ` Pekka Enberg
2010-03-05 7:17 ` "C. Bergström"
2010-03-05 7:53 ` Ingo Molnar
2010-03-05 15:18 ` Linus Torvalds
2010-03-05 7:44 ` Ingo Molnar [this message]
2010-03-05 7:58 ` Dave Airlie
2010-03-05 8:16 ` Stephane Marchesin
2010-03-05 10:00 ` Making Xorg easier to test (was Re: [git pull] drm request 3) Carlos R. Mafra
2010-03-05 12:54 ` Valdis.Kletnieks
2010-03-05 15:22 ` Matt Turner
2010-03-05 15:41 ` Daniel Stone
2010-03-05 15:49 ` Making Xorg easier to test David Miller
2010-03-05 16:03 ` Alan Cox
2010-03-05 16:06 ` Daniel Stone
2010-03-05 17:50 ` Xavier Bestel
2010-03-05 17:54 ` David Miller
2010-03-05 18:02 ` Jesse Barnes
2010-03-05 18:05 ` David Miller
2010-03-05 15:53 ` Making Xorg easier to test (was Re: [git pull] drm request 3) Linus Torvalds
2010-03-05 16:11 ` Daniel Stone
2010-03-05 16:30 ` Linus Torvalds
2010-03-08 8:57 ` Daniel Stone
2010-03-05 16:26 ` Jesse Barnes
2010-03-05 13:55 ` [git pull] drm request 3 Luc Verhaegen
2010-03-05 16:21 ` Jesse Barnes
2010-03-05 12:38 ` Alan Cox
2010-03-05 14:37 ` David Miller
2010-03-05 14:46 ` Mike Galbraith
2010-03-05 18:05 ` Ingo Molnar
2010-03-05 15:09 ` Alan Cox
2010-03-05 15:11 ` David Miller
2010-03-05 15:17 ` Daniel Stone
2010-03-05 15:26 ` David Miller
2010-03-05 15:40 ` Daniel Stone
2010-03-05 15:48 ` David Miller
2010-03-05 16:02 ` Alan Cox
2010-03-05 16:05 ` David Miller
2010-03-05 17:58 ` Younes Manton
2010-03-05 16:13 ` Linus Torvalds
2010-03-05 16:23 ` Alan Cox
2010-03-05 16:44 ` Linus Torvalds
2010-03-05 17:04 ` Alan Cox
2010-03-05 17:19 ` tytso
2010-03-05 16:04 ` Daniel Stone
2010-03-05 16:06 ` David Miller
2010-03-05 16:31 ` Alan Cox
2010-03-05 17:36 ` Jerome Glisse
2010-03-05 16:46 ` tytso
2010-03-05 19:38 ` Corbin Simpson
2010-03-05 21:01 ` Corbin Simpson
2010-03-05 21:51 ` tytso
2010-03-05 23:50 ` Tilman Schmidt
2010-03-05 17:23 ` Linus Torvalds
[not found] ` <hmra63$898$1@xyzzy.farnsworth.org>
2010-03-06 6:17 ` Dale Farnsworth
2010-03-06 17:21 ` Valdis.Kletnieks
2010-03-05 15:56 ` Luca Barbieri
2010-03-05 16:13 ` Alan Cox
2010-03-05 16:19 ` Linus Torvalds
2010-03-05 16:38 ` Alan Cox
2010-03-05 20:59 ` Felipe Contreras
2010-03-05 16:25 ` Luca Barbieri
2010-03-05 15:42 ` Alan Cox
2010-03-05 16:07 ` Linus Torvalds
2010-03-05 17:42 ` Jeff Garzik
2010-03-05 19:11 ` Justin P. mattock
2010-03-04 19:33 ` Jesse Barnes
2010-03-04 19:12 ` Matthew Garrett
2010-03-04 18:45 ` Linus Torvalds
2010-03-04 18:43 ` Linus Torvalds
2010-03-04 18:50 ` Matthew Garrett
2010-03-04 18:55 ` Linus Torvalds
2010-03-04 19:01 ` Linus Torvalds
2010-03-04 19:04 ` Matthew Garrett
2010-03-04 19:14 ` Linus Torvalds
2010-03-04 19:25 ` Matthew Garrett
2010-03-04 19:41 ` Linus Torvalds
2010-03-04 19:53 ` Matthew Garrett
2010-03-04 20:07 ` Linus Torvalds
2010-03-04 20:46 ` Matthew Garrett
2010-03-04 20:57 ` Stephane Marchesin
2010-03-04 22:54 ` Linus Torvalds
2010-03-04 23:03 ` Dave Airlie
2010-03-04 23:19 ` Linus Torvalds
2010-03-04 23:27 ` Michel Dänzer
2010-03-04 23:28 ` Linus Torvalds
2010-03-04 23:35 ` Dave Airlie
2010-03-04 23:53 ` Linus Torvalds
2010-03-05 0:24 ` Ed Tomlinson
2010-03-05 0:24 ` Kyle McMartin
2010-03-04 23:28 ` Dave Airlie
2010-03-04 23:05 ` Jesse Barnes
2010-03-05 12:26 ` Alan Cox
2010-03-04 22:28 ` Adam Jackson
2010-03-04 23:03 ` Linus Torvalds
2010-03-04 23:14 ` Stephane Marchesin
2010-03-05 12:29 ` Alan Cox
2010-03-05 16:18 ` Adam Jackson
2010-03-04 19:32 ` Jeff Garzik
2010-03-04 22:18 ` Adam Jackson
2010-03-04 22:21 ` Jeff Garzik
2010-03-04 22:59 ` Adam Jackson
2010-03-05 11:24 ` Jeff Garzik
2010-03-05 15:46 ` Adam Jackson
2010-03-05 1:47 ` Robert Hancock
2010-03-05 12:21 ` Alan Cox
2010-03-05 19:30 ` Eric Anholt
2010-03-05 20:39 ` Luca Barbieri
2010-03-06 15:23 ` Sergio Monteiro Basto
2010-03-06 17:40 ` Linus Torvalds
2010-03-06 19:06 ` Sergio Monteiro Basto
2010-03-06 19:28 ` Linus Torvalds
2010-03-06 20:49 ` tytso
2010-03-06 20:52 ` Alan Cox
2010-03-06 22:38 ` tytso
2010-03-04 21:21 ` Maarten Maathuis
2010-03-04 21:22 ` Maarten Maathuis
2010-03-04 21:27 ` Maarten Maathuis
-- strict thread matches above, loose matches on Subject: below --
2010-03-05 22:18 Jonas Ritz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100305074407.GC19703@elte.hu \
--to=mingo@elte.hu \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sf.net \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=skeggsb@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).