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, 6 Apr 2007 12:37:46 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Anthony Liguori <aliguori@...ibm.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	kvm-devel@...ts.sourceforge.net, netdev <netdev@...r.kernel.org>
Subject: Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work


* Anthony Liguori <aliguori@...ibm.com> wrote:

> [...] Did Linux have extremely high quality code in 1994?

yes! It was crutial to strive for extremely high quality code all the 
time. That was the only way to grow Linux's codebase, which was ~300,000 
lines of code in 1994, to the current 7.2+ million lines of code, 
without losing maintainability. Code quality is more important than any 
feature. 99% of feature patches sent to lkml get rejected in the first 
review round on quality/design grounds, it always takes at least a 
couple of iterations to make it nice and clean. Look at Apache, it's 
evolving along the same lines. Or Samba. Or any of the really large and 
important OSS projects. (even X, after years of struggle and stagnation, 
seems to have gotten this point now.) In the past 10 years the OSS 
community wrote more than 1 billion lines of new code (!), and all the 
successful projects have a clean codebase. _It cannot be done any other 
way_, because cleanliness and pride over good code is what keeps 
developers and it is what attracts new developers.

now this doesnt mean that Linux's code quality is good in every spot - 
it's an eternal fight. But the core subsystems are pretty damn clean. 
When i prepare patches for the Linux kernel more than 50% of the work i 
do is related to making the changes clean, or cleaning up some existing 
aspect of the kernel that the new code triggers. Often it's 90% of the 
work!

the 'get functionality now, clean up later' mentality is what leads to 
throwaway, use-once codebases that the majority of closed-source 
projects do. Once the cruft level reaches a certain threshold it's 
cheaper to just throw away old code and just rewrite the whole thing 
(users and costs be damned). Cleanups must not be an afterthought, code 
cleanliness and gradual code evolution is _the_ most valuable property 
of OSS codebases.

i guess my negative Qemu experience is dominated by my recent failure of 
trying to untangle its timer code, so that qemu properly adopts to 
changes in PIT/lapic programming and maps that correctly to OS timers. 
(so that a dynticks/NO_HZ guest's reduced irq rate becomes visible on 
the host too) I'll be a happy camper if that's fixed ;-)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ