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 07:53:46 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Carlos R. Mafra" <crmafra2@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...helsinki.fi>,
	Ben Skeggs <skeggsb@...il.com>,
	Dave Airlie <airlied@...il.com>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>, dri-devel@...ts.sf.net
Subject: Re: Making Xorg easier to test (was Re: [git pull] drm request 3)



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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ