From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 72CCF1381F3 for ; Tue, 2 Jul 2013 01:44:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C7A47E0B62; Tue, 2 Jul 2013 01:44:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D5F99E0B25 for ; Tue, 2 Jul 2013 01:44:46 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-119-53.nycmny.fios.verizon.net [173.52.119.53]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E951E33E7C4 for ; Tue, 2 Jul 2013 01:44:45 +0000 (UTC) Message-ID: <51D23086.4040300@gentoo.org> Date: Mon, 01 Jul 2013 21:44:38 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Thunderbird/17.0.7 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. References: <20130701164149.131490f8@TOMWIJ-GENTOO> <20130701181749.GA3831@kroah.com> <20130701204516.6151bb40@TOMWIJ-GENTOO> <20130701192324.GA30808@kroah.com> <51D22E95.4000403@gentoo.org> In-Reply-To: <51D22E95.4000403@gentoo.org> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DMCKFAIEVNLEXUIFXDUU" X-Archives-Salt: aa6ec974-cc01-4b0b-9a76-26177329b095 X-Archives-Hash: b975df48cbead8d506a5bf6d269b011b This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DMCKFAIEVNLEXUIFXDUU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/01/2013 09:36 PM, Richard Yao wrote: > On 07/01/2013 03:23 PM, Greg KH wrote: >> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote: >>>>> Q: What about my stable server? I really don't want to run this >>>>> stuff! >>>>> >>>>> A: These options would depend on !CONFIG_VANILLA or >>>>> CONFIG_EXPERIMENTAL >>>> >>>> What is CONFIG_VANILLA? I don't see that in the upstream kernel tre= e >>>> at all. >>>> >>>> CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to >>>> have a problem with this. >>> >>> Earlier I mentioned "2) These feature should depend on a non-vanilla = / >>> experimental option." which is an option we would introduce under the= >>> Gentoo distribution menu section. >> >> Distro-specific config options, great :( >> >>>>> which would be disabled by default, therefore if you keep this >>>>> option the way it is on your stable server; it won't affect you. >>>> >>>> Not always true. Look at aufs as an example. It patches the core >>>> kernel code in ways that are _not_ accepted upstream yet. Now you a= ll >>>> are running that modified code, even if you don't want aufs. >>> >>> Earlier I mentioned "3) The patch should not affect the build by >>> default."; if it does, we have to adjust it to not do that, this is >>> something that can be easily scripted. It's just a matter of embeddin= g >>> each + block in the diff with a config check and updating the counts.= >> >> Look at aufs as a specific example of why you can't do that, otherwise= , >> don't you think that the aufs developer(s) wouldn't have done so? >=20 > I am accquainted with the developer of a stackable filesystem developer= =2E I should probably proofread multiple times before I send emails. Anyway, that should have been: > I am acquainted with the developer of a stackable filesystem. > According to what he has told me in person offline, the developers on > the LKML cannot decide on how a stackable filesystem should be > implemented. I was told three different variations on the design that > some people liked and others didn't, which ultimately kept the upstream= > kernel from adopting anything. I specifically recall two variations, > which were doing it as part of the VFS and doing it as part of ext4. If= > you want to criticize stackable filesystems, would you lay out a > groundwork for getting one implemented upon which people will agree? >=20 >> The goal of "don't touch any other kernel code" is a very good one, bu= t >> not always true for these huge out-of-tree kernel patches. Usually th= at >> is the main reason why these patches aren't merged upstream, because >> those changes are not acceptable. >=20 > I was under the impression that there were several reasons for patches > not being merged upstream: >=20 > 1. Lack of signed-off > 2. Code drop that no one will maintain > 3. Subsystem maintainers saying no simply because they do not like > . > 4. Risk of patent trolls > 5. Actual technical reasons >=20 >> So be very careful here, you are messing with things that are rejected= >> by upstream. >> >> greg k-h >> >=20 > Only some of the patches were rejected. Others were never submitted. Th= e > PaX/GrSecurity developers prefer their code to stay out-of-tree. As one= > of the people hacking on ZFSOnLinux, I prefer that the code be > out-of-tree. That is because fixes for other filesystems are either hel= d > back by a lack of system kernel updates or held hostage by regressions > in newer kernels on certain hardware. >=20 > With that said, being in Linus' tree does not make code fall under some= > golden standard for quality. There are many significant issues in code > committed to Linus' the kernel, some of which have been problems for > years. Just to name a few: >=20 > 1. Doing `rm -r /dir` on a directory tree containing millions of inodes= > (e.g. ccache) on an ext4 filesystem mounted with discard with the CFQ I= O > elevator will cause a system to hang for hours on pre-SATA 3.1 hardware= =2E > This is because TRIM is a non-queued command and is being interleaved > with writes for "fairness". Incidentally, using noop turns a multiple > hour hang into a laggy experience of a few minutes. >=20 > 2. aio_sync() is unimplemented, which means that there is no sane way > for userland software like QEMU and TGT to be both fast and guarantee > data integrity. A single crash and your guest is corrupted. It would > have been better had AIO never been implemented. >=20 > 3. dm-crypt will reorder write requests across flushes. That is because= > upon seeing a write, it sends it to a work queue to be processed > asynchronously and upon seeing a flush, it immediately processes it. A > single kernel panic or sudden power loss can damage filesystems stored > on it. >=20 > 4. Under low memory conditions with hundreds of concurrent threads (e.g= =2E > package builds), every thread will enter direct reclaim and there will > be a remarkable drop in system throughput, assuming that the system doe= s > not lockup. There is a fairly substantial amount of time wasted after > one thread finishes direct reclaim in other threads because they will > still be performing direct reclaim afterward. >=20 > 5. The Linux 3.7 nouveau rewrite broke kexec support. The graphics > hardware will not reinitialize properly. >=20 > 6. A throttle mechanism introduced for memory cgroups can cause the > system to deadlock whenever it is holding a lock needed for swap and > enters direct reclaim with a significant number of dirty pages. >=20 > 7. Code has been accepted on multiple occasions that does not compile > and the build failures persist for weeks if not months after Linus' tag= =2E > I sent a patch to fix one failure. It was rejected because I had fixed > code to compile with -Werror, people thought that -Werror should be > removed (and therefore was no reason to fix the warnings) and we went 2= > months until someone wrote a patch that people liked to fix it. For a > current example of accepted code failing to build, look here: >=20 > https://bugzilla.kernel.org/show_bug.cgi?id=3D38052 >=20 > Note that I have not checked Linus' tree to see if that bug is still > current, but the bug itself appears to be open as of this writing. >=20 > There are plenty more technical issues, but these are just my pet > peeves. If you want more examples, you could look at the patches people= > send you each day and ask yourself how many are things that could have > been caught had people been more careful during review. For instance, > look at the barrier patches that were done around Linux 2.6.30. What > prevented those from being caught by review years earlier? >=20 > Being outside Linus' tree is not synonymous with being bad and being ba= d > is not synonymous with being rejected. It is perfectly reasonable to > think that there are examples of good code outside Linus' tree. > Furthermore, should the kernel kernel choose to engage that out-of-tree= That should have been: > Furthermore, should the kernel team choose to engage that out-of-tree > code, my expectation is that its quality will improve as they do testin= g > and write patches. >=20 ------enig2DMCKFAIEVNLEXUIFXDUU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0jCJAAoJECDuEZm+6ExkSnkP/RGVTPEeErGH/qVri+/TTty+ Hfmwb8PX3TtLHJv7UXGyMiDFVZuLhgdtvOOLs7Teg9P/YG1wu5140ewDX9Rep4L2 +KKOnn35hI6fFX6jVfclMfv0dJ7PHMOePOymX+uJj9LI3EjsVzhdwaXJkF+BBWsr 8K29G0O3P2Zy/TkwLlw+1nKPZZsmKN1/4cj6D6Cs9z/8NNYtlLn2wBdgInoP9Ejn qsmyEgMR3qWHruD0usjVfojduVubIfRLT+75hQbG2mhDOsLltqcyY55IVgypAxwM AmrzuwOEVrPusfV8wikBUVsDpOl0fx6ENEUyc14vM9ojHa5Oxshz6pUqY4Rg0u+B Q0pdc+zYMa+V44dZntiHIgdz2m9Kf8c5rNnxqw4CBC6XLGUVzzGvAhjpcG3qV0Zt qYPHiBYFKQxOLK5I+xO2PWUNbz5wuQA0fbJw5rjHihaMAXiyK2bZ0F1vEnaCBKoo gLZcYRDBCj3XS9hxjzQXTJvxOYSc1GXThHPcwVU/qIGoYgVCN3+puIiF7ZdXpb3k a3A5dQ0FEbK9BEHgnBNBf5BRCkbyDUxbhk7Cawhh8QkIClxlhrDCYeLxgHKsYeDq CU4c2tdpjh2N7G0RuDP3TJ/epTM00HGTTvQI+v4Og+pQOcOqYHPwxJpsqbUjwo5U X/eG2jpPUx328lvh2J27 =gpzl -----END PGP SIGNATURE----- ------enig2DMCKFAIEVNLEXUIFXDUU--