Prev: [PATCH 1/1] gitignore: do not ignore include/linux/
Next: [PATCH 0/3] ramzswap: Eliminate stale data in compressed memory
From: Carlos R. Mafra on 5 Mar 2010 05:10
On Fri 5.Mar'10 at 8:44:07 +0100, Ingo Molnar wrote:
>
> 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:

I agree 100% with this!

I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because
it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install
and I am ready to test the bleeding edge kernel.
And everytime I complained about something breaking it got fixed.

Really, testing the linux kernel is a hobby for me because it is easy.

Whereas everytime I wanted to do that with Xorg it was such a pain that
I want to keep away from that mess.

> - 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.

True!

Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
maintainers and keeping the whole thing tied up? Why can't it mimic the
'make menuconfig' way of selecting what to compile to have the guarantee that
the whole thing will simply work nicely together?

If this could be done for the kernel (which from my user POV seems much more
complicated), I guess it could be done with Xorg. And Linux would have
more Xorg testers and be better as a whole.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 5 Mar 2010 08:00
On Fri, 05 Mar 2010 11:00:30 +0100, "Carlos R. Mafra" said:

> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

Feel free to do so. Note that you'll hit 2 problems:

1) In the kernel, the sysadmin can almost always get away with saying
"I have no XYZ devices" or "I only have ext4 filesystems" or similar choices,
and have the resulting kernel still support basically all the syscalls
(unless you start going into CONFIG_EMBEDDED and doing some *major* surgury).
Over on the X side of the fence, there aren't as many options that don't
involve dropping major chunks of the functionality. You *sure* that nothing
on your system depends on the XRandR extension? ;)

2) Lately, the X server is *already* highly modular and different components
built from different source trees. Note that the base X server is only about
half the size of the kernel RPM - there really isn't much left to trim out of
the base server anymore.

ncftp ...velopment/source/SRPMS > dir kern* xorg*
-rw-r--r-- 1 263 263 66965350 Feb 26 18:03 kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm
-rw-r--r-- 1 263 263 44300 Feb 27 01:39 xorg-sgml-doctools-1.1.1-4.fc12.src.rpm
-rw-r--r-- 2 263 263 2229508 Feb 11 02:23 xorg-x11-apps-7.4-10.fc13.src.rpm
-rw-r--r-- 1 263 263 8250097 Feb 27 00:06 xorg-x11-docs-1.3-6.fc12.src.rpm
-rw-r--r-- 1 263 263 9718 Feb 27 03:27 xorg-x11-drivers-7.3-13.fc12.src.rpm
-rw-r--r-- 2 263 263 263291 Feb 5 21:40 xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm
-rw-r--r-- 2 263 263 271426 Feb 5 23:03 xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm
-rw-r--r-- 1 263 263 293991 Feb 27 01:02 xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm
-rw-r--r-- 2 263 263 247603 Feb 5 19:49 xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm
-rw-r--r-- 1 263 263 273849 Feb 26 20:22 xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm
-rw-r--r-- 1 263 263 475771 Feb 19 00:50 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm
-rw-r--r-- 1 263 263 354400 Feb 27 01:17 xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm
-rw-r--r-- 2 263 263 296790 Feb 5 16:10 xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm
-rw-r--r-- 2 263 263 257700 Feb 5 19:48 xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 260227 Feb 5 16:26 xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm
-rw-r--r-- 2 263 263 537577 Feb 5 21:59 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm
-rw-r--r-- 2 263 263 254313 Feb 9 13:19 xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm
-rw-r--r-- 1 263 263 252387 Feb 17 05:13 xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm
-rw-r--r-- 2 263 263 608480 Feb 5 23:07 xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm
-rw-r--r-- 2 263 263 361698 Feb 5 21:40 xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm
-rw-r--r-- 2 263 263 244962 Feb 9 13:48 xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm
-rw-r--r-- 2 263 263 289677 Feb 5 22:38 xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 281904 Feb 5 20:33 xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm
-rw-r--r-- 1 263 263 978993 Feb 12 07:15 xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm
-rw-r--r-- 2 263 263 305926 Feb 5 19:26 xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm
-rw-r--r-- 2 263 263 296974 Feb 5 19:22 xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm
-rw-r--r-- 2 263 263 492204 Feb 5 20:02 xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm
-rw-r--r-- 2 263 263 427579 Feb 5 20:39 xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm
-rw-r--r-- 2 263 263 318263 Feb 9 13:52 xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm
-rw-r--r-- 2 263 263 254590 Feb 5 20:17 xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm
-rw-r--r-- 2 263 263 290495 Feb 5 22:02 xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm
-rw-r--r-- 2 263 263 91334 Feb 18 16:59 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
-rw-r--r-- 2 263 263 449803 Feb 9 12:19 xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm
-rw-r--r-- 2 263 263 475028 Feb 9 12:26 xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm
-rw-r--r-- 2 263 263 248668 Feb 9 12:27 xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm
-rw-r--r-- 2 263 263 280184 Feb 5 22:08 xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm
-rw-r--r-- 2 263 263 424771 Feb 5 19:36 xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm
-rw-r--r-- 2 263 263 746854 Feb 11 02:43 xorg-x11-drv-radeonhd-1.3.0-5.4.20100210git.fc13.src.rpm
-rw-r--r-- 2 263 263 323181 Feb 5 20:32 xorg-x11-drv-rendition-4.2.2-5.fc13.src.rpm
-rw-r--r-- 2 263 263 285445 Feb 5 20:21 xorg-x11-drv-s3-0.6.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 308304 Feb 9 12:44 xorg-x11-drv-s3virge-1.10.4-2.fc13.src.rpm
-rw-r--r-- 2 263 263 336582 Feb 5 18:39 xorg-x11-drv-savage-2.3.1-2.fc13.src.rpm
-rw-r--r-- 2 263 263 587339 Feb 5 20:09 xorg-x11-drv-siliconmotion-1.7.3-3.20100122.fc13.src.rpm
-rw-r--r-- 2 263 263 651516 Feb 5 16:33 xorg-x11-drv-sis-0.10.2-2.fc13.src.rpm
-rw-r--r-- 2 263 263 329764 Feb 5 19:46 xorg-x11-drv-sisusb-0.9.3-2.fc13.src.rpm
-rw-r--r-- 1 263 263 316085 Feb 18 23:34 xorg-x11-drv-synaptics-1.2.1-4.fc14.src.rpm
-rw-r--r-- 2 263 263 298619 Feb 5 20:35 xorg-x11-drv-tdfx-1.4.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 305737 Feb 5 19:56 xorg-x11-drv-trident-1.3.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 292468 Feb 5 22:28 xorg-x11-drv-tseng-1.2.3-2.fc13.src.rpm
-rw-r--r-- 2 263 263 250893 Feb 5 21:17 xorg-x11-drv-v4l-0.2.0-4.fc13.1.src.rpm
-rw-r--r-- 2 263 263 259661 Feb 5 16:27 xorg-x11-drv-vesa-2.2.1-2.fc13.src.rpm
-rw-r--r-- 1 263 263 281386 Feb 12 06:37 xorg-x11-drv-vmmouse-12.6.6-1.fc13.src.rpm
-rw-r--r-- 2 263 263 288560 Feb 9 13:16 xorg-x11-drv-vmware-10.16.7-3.fc13.src.rpm
-rw-r--r-- 2 263 263 255811 Feb 5 22:30 xorg-x11-drv-void-1.3.0-5.fc13.src.rpm
-rw-r--r-- 2 263 263 268147 Feb 5 21:35 xorg-x11-drv-voodoo-1.2.3-2.fc13.src.rpm
-rw-r--r-- 1 263 263 2356579 Mar 4 00:05 xorg-x11-drv-wacom-0.10.4-5.20100219.fc14.src.rpm
-rw-r--r-- 2 263 263 521166 Feb 5 22:42 xorg-x11-font-utils-7.2-11.fc13.src.rpm
-rw-r--r-- 1 263 263 10315388 Feb 27 00:41 xorg-x11-fonts-7.2-9.fc12.src.rpm
-rw-r--r-- 2 263 263 2165779 Feb 25 21:56 xorg-x11-proto-devel-7.4-36.fc13.src.rpm
-rw-r--r-- 1 263 263 371754 Feb 26 20:39 xorg-x11-resutils-7.1-9.fc12.src.rpm
-rw-r--r-- 1 263 263 35493506 Mar 4 05:51 xorg-x11-server-1.7.99.901-10.20100304.fc14.src.rpm
-rw-r--r-- 2 263 263 1418431 Feb 5 16:50 xorg-x11-server-utils-7.4-15.fc13.src.rpm
-rw-r--r-- 2 263 263 247211 Feb 12 05:41 xorg-x11-twm-1.0.3-6.fc13.src.rpm
-rw-r--r-- 2 263 263 66840 Feb 9 12:03 xorg-x11-util-macros-1.5.0-1.fc13.src.rpm
-rw-r--r-- 2 263 263 900166 Feb 9 11:40 xorg-x11-utils-7.4-9.fc13.src.rpm
-rw-r--r-- 1 263 263 123367 Feb 27 03:05 xorg-x11-xauth-1.0.2-7.fc12.src.rpm
-rw-r--r-- 2 263 263 108420 Feb 5 20:51 xorg-x11-xbitmaps-1.1.0-1.fc13.src.rpm
-rw-r--r-- 1 263 263 415159 Feb 20 21:12 xorg-x11-xdm-1.1.6-16.fc13.src.rpm
-rw-r--r-- 1 263 263 481668 Feb 27 02:56 xorg-x11-xfs-1.0.5-6.fc12.src.rpm
-rw-r--r-- 1 263 263 282714 Feb 26 22:00 xorg-x11-xfwp-1.0.1-10.fc12.src.rpm
-rw-r--r-- 1 263 263 153187 Feb 27 10:54 xorg-x11-xinit-1.0.9-15.fc14.src.rpm
-rw-r--r-- 2 263 263 681572 Feb 5 16:57 xorg-x11-xkb-utils-7.4-7.fc13.src.rpm
-rw-r--r-- 2 263 263 308671 Feb 11 02:35 xorg-x11-xsm-1.0.2-13.fc13.src.rpm
-rw-r--r-- 1 263 263 110396 Feb 27 01:45 xorg-x11-xtrans-devel-1.2.2-4.fc12.src.rpm

From: Matt Turner on 5 Mar 2010 10:30
On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2(a)gmail.com> wrote:
> Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> maintainers and keeping the whole thing tied up? Why can't it mimic the
> 'make menuconfig' way of selecting what to compile to have the guarantee that
> the whole thing will simply work nicely together?

You must not follow X development at all. His name is Keith Packard.

Matt Turner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Stone on 5 Mar 2010 10:50
On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote:
> On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra <crmafra2(a)gmail.com> wrote:
> > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
> > maintainers and keeping the whole thing tied up? Why can't it mimic the
> > 'make menuconfig' way of selecting what to compile to have the guarantee that
> > the whole thing will simply work nicely together?
>
> You must not follow X development at all. His name is Keith Packard.

Except that if you look at X lately, you'll realise that we do not have
the resources to even come close to being able to do this properly. We
struggle to support what we have already today, and we've still been
hoping to create a real API, instead of the sad joke that is
/usr/include/xorg/*.h, for the last few years. But we don't have enough
people (or at least enough people who aren't busy with the other parts
of their day jobs, or kids, or burnout, or whatever) to do it.

I understand that you guys are upset about this, so maybe you'd like to
donate, say, 10% of your developer base to help out? That'd be pretty
ace.

Cheers,
Daniel
From: Linus Torvalds on 5 Mar 2010 11:00


On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
>
> Whereas everytime I wanted to do that with Xorg it was such a pain that
> I want to keep away from that mess.

Actually, take it from me: Xorg is _pleasant_ to test these days.

Ok, so that's partly compared to the mess it _used_ to be, but it's really
night and day. The whole build system was so incredibly baroque and heavy
that you really had to understand it deeply if you wanted to do anything
fancy.

And the non-fancy alternative was to just build the whole thing, which
took _hours_ even on fast machines because the build system overhead was
near-infinite (I dunno, maybe parallel builds could be made to work, but
it took more brain-power than I could ever put into it).

These days, there's a few dependencies you need to know about (I do agree
that from a user perspective the thing might have been made a bit _too_
modular) but they are generally fairly trivial, and there are scripts to
download all the drivers and misc utilities needed.

And the modularization often works: you can often (but by no means always;
it does require that the other parts are "close enough" and that there
haven't been any major changes) just have the source code to the one
driver you care about, and recompile and install just that _single_
driver.

I've done it. It's becautiful when it works. And it's a major pain when
you notice it didn't work, and you needed to get the whole server and
libdrm trees after all, and now you're not replacing single files any
more and have little idea what it will stomp on in your distro.

So it really is very convenient when it works. And X doesn't have
thousands of drivers like the kernel (maybe 10-15 that people care about
at all, and about three or four that actually really matter), and there
are seldom huge changes that affect them all, so the modularization
doesn't turn totally crazy.

So I can see where the Xorg people really like their new modular world. It
does work, it's _sooo_ much better than the mess it used to be, and the
problems are fairly manageable when they do happen.

The modular approach really works very well when there aren't lots of
interactions between the modules, and when the modules are few enough that
it isn't a total disaster (imagine doing a change that requires changes to
all drivers in Xorg, vs doing a change that requires changes to all
drivers in the kernel - the modular approach simply wouldn't work for the
latter case, because you'd spend all your time just chasing down external
users).

That said, the _one_ thing I really wish could be done would be to make it
easier to install things side-by-side - and with the modularization, you
really do want to do it module-by-module. One of the things that makes it
so easy to test the kernel is that when you install one kernel, that
doesn't affect the others, and you can go back-and-forth in testing.
That's really important, because it makes testing trivial and non-scary
even in the presense of issues that makes the new version unusable.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: [PATCH 1/1] gitignore: do not ignore include/linux/
Next: [PATCH 0/3] ramzswap: Eliminate stale data in compressed memory