[rfc] Merge kexec-tools into the kernel tree

[Eric W. Biederman]

Michael Neuling <mikey at neuling.org> writes:

>> > After all the excitement of relocating kexec-tools from
>> > one location on kernel.org to another last week it was
>> > suggested to me by Michael Neuling that the merging
>> > kexec-tools into the kernel tree would be a good idea.
>> >
>> > Given that there have been a bunch of issues with kexec
>> > on power that this would resolve. and there is precedence
>> > for tools in the kernel tree, this sounds entirely reasonable to me.
>> > So with my kexec-tools maintainer hat on, I would like to start
>> > a conversation about this.
>> 
>> What are the issues with kexec on power?  Did someone fail to maintain
>> ABI compatibility?
>> 
>> The interface isn't even supposed to be linux specific, so I can't
>> imagine what would motivate moving this into the kernel tree.
>> 
>> I'm afraid that someone has a good answer for why their lives would be
>> simpler if /sbin/kexec was in the kernel tree and I will be absolutely
>> horrified and about someones stupidity when I hear that answer.
>
> I may have misrepresented how bad it is for power to Horms.  None of the
> issues would be solved by a merge, but it would make life easier IMHO.
>
> In power we've added features to kexec which have required changes to
> both the kernel and kexec-tools.  These have been backwards compatible,
> so not to break to the ABI.  The problem here is getting users and
> distros to take the correct versions of both sources if they want this
> new feature.

I'm still scratching my head.  What new features were added recently
that required this work?  The device tree or something else?

What you are describing seems to be the case for adding any new kernel
feature.

> Similarly with bugs.  We recently went through a round of bug fixes for
> new larger power7 machines.  We found bugs in both kexec-tools and the
> kernel.  That meant we had to ensure users and distros were getting
> correctly updated versions of both tools.
>
> Neither of these problems are show stoppers or power specific but I
> think it would make life easier in these scenarios if the sources were
> merged.  We could just tell users and distros to grab (say) 2.6.35
> sources and we'd know they'd be right for both userspace and the kernel.

You are proposing optimizing for change when change should and generally
is infrequent?

> Also, I think kexec-tools would benefit from the same release process as
> the kernel, with a merge window followed by bug fixes.  Of course,
> kexec-tools doesn't need to be in the kernel for this, but it might be
> easier for Horms to enforce if it was.  kexec-tools only gets a trickle
> patches.

You would like to see a higher barrier to entry for your patches to make
it into /sbin/kexec?  Someone else to help you test so that you get fewer
buggy patches into releases?

> I'd also hope that kexec-tools would get some addition community
> exposure and TLC if they were in the kernel sources.
>
> My question is, why not?  What qualifies a tool to be added to tools/?
> I think kexec-tools are tied to the kernel at least as much as perf is.
> Certainly the ABI for the image we are booting into is not Linux
> specific, but should that disqualify it from being in tools/?

The grand and glorious vision for /sbin/kexec is that it can boot any
interesting OS kernel.  From RHEL, SLES, Fedora, Unbuntu definitely,
but also the BSDs, Mac OS X, and Windows.  I don't see how moving into
the kernel tree making that vision any easier.  Do I need a different
version of kexec to boot an Ubunutu kernel versus a RHEL kernel,
versus a kernel.org kernel?

On the flip side of it in general kexec should not be assumed to be
the only boot loader using various kernel interfaces.  So when you add
a new feature sure add the feature to /sbin/kexec but don't forget
someone eventually will want that feature in another boot loader as
well.

I can imagine arguments for putting the sources for /sbin/kexec into
the kernel tree but I don't see them being made here.

If we talk about analyzing and filtering crash dumps, I can totally
see an argument for putting something under tools/ if the authors of
mkdumpfile and crash are interested.  Those tools fundamentally really
do follow kernel internals.

I may be dense but I don't how everything will be better if sprinkled
with penguin pee.

Eric