Re: [rfc] Merge kexec-tools into the kernel tree
From: AmÃrico Wang
Date: Wed Aug 04 2010 - 23:18:17 EST
On Thu, Aug 05, 2010 at 09:11:26AM +1000, Michael Neuling wrote:
>> > 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
>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.
I am afraid kexec-tools is not alone, there are plenty of user-space
applications which rely on some new kernel feature after a specific version.
If this could be a reason for inclusion into kernel tree, then much more
applications shall be included too. And if this happened, Linux would be
more like *BSD.
Also, this is a big reason why linux distributions exist. They are
responsible for collecting the right version of some application and the
right version of kernel that makes them work together.
So, I think _we_ should get used to this unless Linus decides to change
>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.
I think the solution is documention, or release notes, not including
it into kernel tree.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/