From: Richard Yao <ryao@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
Date: Mon, 01 Jul 2013 21:44:38 -0400 [thread overview]
Message-ID: <51D23086.4040300@gentoo.org> (raw)
In-Reply-To: <51D22E95.4000403@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 7237 bytes --]
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 tree
>>>> 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 all
>>>> 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 embedding
>>> 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?
>
> I am accquainted with the developer of a stackable filesystem developer.
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?
>
>> The goal of "don't touch any other kernel code" is a very good one, but
>> not always true for these huge out-of-tree kernel patches. Usually that
>> is the main reason why these patches aren't merged upstream, because
>> those changes are not acceptable.
>
> I was under the impression that there were several reasons for patches
> not being merged upstream:
>
> 1. Lack of signed-off
> 2. Code drop that no one will maintain
> 3. Subsystem maintainers saying no simply because they do not like
> <insert non-technical reason here>.
> 4. Risk of patent trolls
> 5. Actual technical reasons
>
>> So be very careful here, you are messing with things that are rejected
>> by upstream.
>>
>> greg k-h
>>
>
> Only some of the patches were rejected. Others were never submitted. The
> 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 held
> back by a lack of system kernel updates or held hostage by regressions
> in newer kernels on certain hardware.
>
> 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:
>
> 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 IO
> elevator will cause a system to hang for hours on pre-SATA 3.1 hardware.
> 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.
>
> 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.
>
> 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.
>
> 4. Under low memory conditions with hundreds of concurrent threads (e.g.
> package builds), every thread will enter direct reclaim and there will
> be a remarkable drop in system throughput, assuming that the system does
> 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.
>
> 5. The Linux 3.7 nouveau rewrite broke kexec support. The graphics
> hardware will not reinitialize properly.
>
> 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.
>
> 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.
> 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:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=38052
>
> 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.
>
> 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?
>
> Being outside Linus' tree is not synonymous with being bad and being bad
> 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 testing
> and write patches.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2013-07-02 1:44 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 14:41 [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration Tom Wijsman
2013-07-01 15:14 ` Ben de Groot
2013-07-01 15:20 ` [gentoo-dev] Re: [gentoo-kernel] " Jeff Horelick
2013-07-01 18:30 ` Anthony G. Basile
2013-07-01 19:07 ` Tom Wijsman
2013-07-01 19:24 ` Greg KH
2013-07-01 19:40 ` Tom Wijsman
2013-07-01 19:55 ` Fabio Erculiani
2013-07-01 19:59 ` Pacho Ramos
2013-07-01 20:03 ` Fabio Erculiani
2013-07-01 20:06 ` Tom Wijsman
2013-07-01 20:24 ` Christoph Junghans
2013-07-01 20:27 ` Fabio Erculiani
2013-07-01 20:25 ` Rick "Zero_Chaos" Farina
2013-07-01 21:18 ` Anthony G. Basile
2013-07-01 16:20 ` [gentoo-dev] " Rick "Zero_Chaos" Farina
2013-07-01 16:28 ` hasufell
2013-07-01 17:35 ` Tom Wijsman
2013-07-01 17:52 ` Rick "Zero_Chaos" Farina
2013-07-05 0:19 ` Mike Pagano
2013-07-17 21:11 ` Donnie Berkholz
2013-07-01 18:17 ` [gentoo-dev] Re: [gentoo-kernel] " Greg KH
2013-07-01 18:38 ` Markos Chandras
2013-07-01 18:56 ` Tom Wijsman
2013-07-01 19:09 ` Matthew Summers
2013-07-01 19:25 ` Tom Wijsman
2013-07-01 19:33 ` Greg KH
2013-07-01 19:50 ` Tom Wijsman
2013-07-03 10:45 ` [gentoo-dev] " Steven J. Long
2013-07-03 12:42 ` Tom Wijsman
2013-07-04 2:00 ` Walter Dnes
2013-07-04 5:37 ` [gentoo-dev] " Steven J. Long
2013-07-04 7:41 ` [gentoo-dev] " Tom Wijsman
2013-07-04 5:27 ` [gentoo-dev] " Steven J. Long
2013-07-04 7:57 ` Tom Wijsman
2013-07-05 8:38 ` Steven J. Long
2013-07-05 9:04 ` Tom Wijsman
2013-07-09 15:12 ` Steven J. Long
2013-07-01 20:14 ` Markos Chandras
2013-07-01 20:25 ` Fabio Erculiani
2013-07-01 21:26 ` Anthony G. Basile
2013-07-01 21:30 ` Fabio Erculiani
2013-07-01 21:55 ` Anthony G. Basile
2013-07-01 20:31 ` Tom Wijsman
2013-07-01 18:45 ` Tom Wijsman
2013-07-01 19:23 ` Greg KH
2013-07-01 19:33 ` Tom Wijsman
2013-07-01 21:17 ` Anthony G. Basile
2013-07-01 21:24 ` Greg KH
2013-07-01 21:53 ` Anthony G. Basile
2013-07-02 8:31 ` gentoo-checkconf script " Michael Weber
2013-07-03 11:40 ` [gentoo-dev] Re: gentoo-checkconf script " Steven J. Long
2013-07-01 21:55 ` [gentoo-dev] " Tom Wijsman
2013-07-02 1:36 ` Richard Yao
2013-07-02 1:44 ` Richard Yao [this message]
2013-07-02 1:56 ` Greg KH
2013-07-02 3:29 ` Richard Yao
2013-07-02 3:40 ` Richard Yao
2013-07-02 19:39 ` Greg KH
2013-07-02 3:31 ` Richard Yao
2013-07-02 7:36 ` [gentoo-dev] " Sergei Trofimovich
2013-07-02 8:21 ` Fabio Erculiani
2013-07-02 8:37 ` Michael Weber
2013-07-02 8:52 ` Michael Weber
2013-07-02 18:16 ` Sergei Trofimovich
2013-07-03 13:06 ` Tom Wijsman
2013-07-03 13:52 ` Sergei Trofimovich
2013-07-03 15:18 ` Tom Wijsman
2013-07-03 16:10 ` Sergei Trofimovich
2013-07-02 10:08 ` Tom Wijsman
2013-07-02 21:48 ` Tomáš Pružina
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=51D23086.4040300@gentoo.org \
--to=ryao@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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