Merge kexec-tools into the kernel tree
in [Kernel]
|
Prev: 2.6.35 vs. 2.6.33: ata_piix does not find any device after piix is loaded
Next: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
From: Américo Wang on 4 Aug 2010 03:20 On Wed, Aug 04, 2010 at 04:06:48PM +0900, Simon Horman wrote: >Hi, > >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. > But why? Just to draw more attentions from kernel community? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 4 Aug 2010 03:40 Simon Horman <horms(a)verge.net.au> writes: > Hi, > > 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. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bernhard Walle on 4 Aug 2010 04:20 * Simon Horman <horms(a)verge.net.au> [2010-08-04 09:06]: > > 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. Well, honestly I don't understand the reason behind it. If it's about dependencies between the kexec binary and the kernel version -- there are also dependencies between makedumpfile and crash to the kernel version. Should we move makedumpfile and crash in the kernel tree, too (which means that we have a GDB copy in the kernel tree)? Regards, Bernhard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Neil Horman on 4 Aug 2010 08:30 On Wed, Aug 04, 2010 at 04:06:48PM +0900, Simon Horman wrote: > Hi, > > 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. > > In order to move the conversation along I have prepared a tree - > a recent clone of Linus's tree + kexec tools. > > http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-in-kernel-tree.git > > I think that a good next step would be to get this tree into linux-next. > And then if all goes well, as Linus to pull the change some time in the future. > > > > > > For reference the steps taken to make the tree above were roughly as follows. > Thanks to Michael for assistance with this. > > git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git > > cd linux-2.6 > > git remote add -f kexec ../kexec-tools > git merge -s ours --no-commit kexec/master > git read-tree --prefix=tools/kexec/ -u kexec/master > git commit -m "Merge kexec-tools into subdirectory tools/kexec" > > > _______________________________________________ > kexec mailing list > kexec(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec It seems to me that this change isn't overly usefull in solving the problems that kexec-tools seems to chronically encounter. The biggest kexec/kernel problem that I seem to encounter during maintence of the package in RHEL isn't ABI compatibility between any kexec/kernel version pair (which can often be mitigated/controlled by merging the source trees), but rather by lack of testing of changes. All to often kernel code authors assume that if something they write or modify works in the kernel during a normal boot, it can be assumed to work just fine in the kdump kernel. That _should_ be the case, bur rarely is it. And unfortunately, that won't be mitigated by tying a kexec and kernel version together. What I think we need is a shorter path from upstream commit to regression/bug detection. Something that would allow someone to validate that kexec works properly after they have made a commit to hardware that they have in hand. Perhaps something in the scripts directory that allows a developer to immediately execute a kexec -e reboot and a kexec -l; sysrq-c crash reboot to validate that their changes are working properly. Perhaps if we added a step to the submission checklist including the running of said script, we'd see less hardware specific regressions. My $0.02 Neil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 4 Aug 2010 11:10
ebiederm(a)xmission.com (Eric W. Biederman) writes: > > 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. Same here. In fact I guess it would be counter productive: it would discourage a stable API between the kernel and the user tool. We're seeing this problem with other user tools which are in the kernel tree. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |