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 >new 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. 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 this model. >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. Thanks.
