* Vivek Goyal <vgo...@redhat.com> wrote:
> On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> > On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > >
> > > - Now we use dracut generated initramfs and it has been growing in
> > > size. Now systemd has been pulled in too.
> >
> > And the solution to that isn't obvious?
>
> Sorry, I did not understand what do you mean by above.
>
> If you are suggesting that move away from dracut, it does not work in
> practice. Initially we wrote our custom code to generate custom
> initramfs, and we were always lagging in terms of what dump targets can
> be supported and kept on constantly fixing the issues which had been
> taken care of in dracut one way or other. So it was like maintaining a
> duplicate initramfs generation tool.
The fundamental design problem is this artificial split of the kernel from
kexec-tools, just to support an arguably exotic feature, which in turn
then tries to support a complex compatibility matrix - making each variant
even more super exotic. There's just not enough usage and not enough
manpower to keep all that tidy ...
If there was tools/kexec/ then many of these constraints and quirks with
old versions would go away: old kernels would come with old kexec tools,
new kernels would come with new kexec tools.
Just look at how tools/perf/ is packaged up with new kernels: you
generally get a new perf with a new kernel version. Alone this eliminates
a fair bit of support complexity and makes it easier to keep users
uptodate.
[ kexec tooling could go even farther: if included in the initramfs then
it could do away with ABI constraints and compatibility expectations
altogether.
This is one of the cases where it _does_ make sense: kexec tools and in
general kernel image analysis is obviously coupled to the kernel's
current data structures. ]
If this was fixed then kexec could step a whole lot further, not just in
terms of robustness, but also in terms of feature set - and, ultimately,
increased usage by users and kernel developers.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
