You are viewing jwboyer

pointless pontifications of a back seat driver - At the playground [entries|archive|friends|userinfo]
jwboyer

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

At the playground [Jul. 8th, 2014|03:25 pm]
Previous Entry Share Next Entry
[Tags|]

A while ago, we had a thread on the Fedora kernel list where people were expressing a desire for easily accessible kernels that contained new and shiny technologies still under development. We've had a number of discussions like that over the years, and none of them ever seem to pan out to something remotely feasible. The patches in question tend to be larger, with no clear upstream path. The one thing we've learned from uprobes, execshield, and now Secure Boot is that carrying non-upstream patches is kind of a nightmare. It makes us different from upstream, creates a maintenance burden, and actually leads to those patches taking even longer to get upstream because there's no impetus once they're "in-distro". So we've been sufficiently hit with the cluebat enough to say "no major non-upstream patches" and to be honest that approach has been working well.

Except that precludes people from working on them, getting userspace ready for them, and improving them. There's a catch-22 there. The features aren't making upstream progress because nobody is using them, but nobody is using them because they aren't easily accessible. Not everyone is willing to build their own kernel just to play with a new toy. Fedora hasn't been willing to take the hit so they can easily use something that might not actually get upstream (see aufs). So what can anyone do?

The Fedora kernel team has thought about this for a while. How do we deliver something people are asking for without impacting the rest of the distro. The rawhide nodebug repo has shown that simply delivering a side-band kernel doesn't drastically increase the maintenance burden, but that isn't really a great comparison. That is literally the same kernel, just with the debug options disabled. However, the introduction of Coprs in Fedora gives us another option.

The kernel team first used a Copr to work on the kernel-core/kernel-modules packaging split before landing it in rawhide. The Cloud team was able to point their instances at that repo and test it out. This actually worked out really well and we fixed a number of bugs before they hit rawhide. The content of the kernel was still a 100% match to the mainline Fedora kernel, but the packaging difference was enough to prove the mechansim worked well enough.

So with that in mind, I've decided to create a kernel-playground Copr. The idea behind this is to provide easily consumable kernel builds with some of the things people have been requesting for a while now. Before we get to specifics, here's the playground rules:

* This is not a "supported" kernel. Bugs filed against the Fedora kernel component with the kernel-playground kernel will be closed. If the bug clearly lands in one of the features being carried, we'll make attempts to forward the information to the relevant upstream developers. If there are issues we can still discuss them, but we want to keep the Fedora distro and it's process/tracking isolated from this like we would with any other non-standard kernel.

* The kernel-playground build will roughly track rawhide, with selected features/patches added on top. I say roughly because it will not receive a build for every rawhide build done like the nodebug repo does. The tentative plan is to update it once per upstream -rc and final release.

* x86_64 only. In the future, other 64-bit architectures might be possible.

* There are no guarantees around feature/patch additions. We'll do our best to keep things integrated, but we might have to drop additions if they become too much work. There are also no plans to "graduate" features from the playground kernel to the standard Fedora kernel. "When it gets upstream" is still the default answer there.

* In all likelyhood, this kernel will crash on your machine at some point. It will probably even eat data. DO NOT RUN IT ON ANYTHING YOU RELY ON HEAVILY. Make sure whatever data you care about is backed up, etc. We provide this AS-IS, with no warranty, and are not liable for anything. (The same is true of Fedora kernels as well, but doubly so for kernel-playground.)

OK, now that we have that out of the way, let's talk about what is actually in kernel-playground. At the moment there are two additions on top of the standard rawhide kernel; overlayfs (v22) and kdbus.

Overlayfs is one of the top competing "union" filesystems out there, and has actually been posted for review for the past few releases. It has the best chance of landing upstream sometime this decade, and there has been interest in it for quite a while. I believe things like Docker would also be able to make use of it as a backend. I'll track upstream submissions and update accordingly.

kdbus is of course the thing that Lennart Poettering and Kay Sievers have been talking about at various conferences for a while now. It is the in-kernel d-bus replacement. It has not been submitted for upstream review yet, but systemd already has support for it and things seem to be progressing well there.

I'm open to adding more content if there's a reasonable enough purpose to do so. Some interest in the live-patching kernel solutions (kpatch/kGraft) has been expressed, though we won't be producing patch updates so that still requires heavy user involvement to actually be useful. Backported btrfs updates from the latest development tree has also been floated as an idea. If you have a feature/technology you'd like to see, shoot an email to the Fedora kernel list and we can chat about it.
linkReply

Comments:
From: (Anonymous)
2014-07-09 11:33 pm (UTC)

(Link)

What about including BFS, so you can test it without the need to compile a new kernel on your own? No need to default to BFS.
From: jwboyer
2014-07-10 04:03 pm (UTC)

(Link)

I'm assuming you mean the scheduler and not the filesystem. If you mean the filesystem, we can turn that on in kernel-playground.

So BFS probably isn't a great fit. There are a couple of reasons for this. 1) It has no chance of getting upstream. The author isn't even trying to upstream it. Aufs suffers from this same problem, which is why we aren't carrying that. 2) It's intentionally not really scalable. 3) It's incompatible with a nubmer of the RCU options Fedora has enabled. 4) The patch inexplicably removes the menu choice for slab allocators.

It's not really an additive feature on top of Fedora, but rather something that would fundamentally change things. Issue #1 alone is enough to make me avoid it.
From: (Anonymous)
2014-07-13 01:52 am (UTC)

Possible kernels

(Link)

What about things like PREEMPT/RT, the new DEADLINE scheduler, or Andrea Mazzoleni's raid lib (https://lkml.org/lkml/2014/1/10/150)?
From: jwboyer
2014-07-14 02:38 pm (UTC)

Re: Possible kernels

(Link)

The -rt kernel isn't a great candidate here. RT has significant specific meaning, and it isn't additive on top of the Fedora kernel. It is more of a replacement.

The deadline I/O scheduler was merged in 3.14 and is already enabled in F20 and newer kernels.

The snapraid/raid lib patches haven't been posted or followed up on since February. It's unclear if they are still getting worked on, and the patches provided require changes to btrfs to actually be used by anything. Adding the library itself doesn't seem overly useful at this point. We have enough troubles with btrfs as it is so I don't think we want to add new raid code into the mix there.

Good questions though.
From: (Anonymous)
2014-07-13 09:47 pm (UTC)

will builds for f20 or f21 be added

(Link)

It'd be cool to test these in at least f21 once it is alpha stage and beyond
From: jwboyer
2014-07-14 02:24 pm (UTC)

Re: will builds for f20 or f21 be added

(Link)

F21 will be added once it's available as a chroot in COPR. That isn't there yet. I won't be adding an F20 version.