On 04/01/2013 06:34 AM, Vivek Goyal wrote:
> On Tue, Mar 26, 2013 at 02:14:18PM -0400, Vivek Goyal wrote:
>> On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
>>> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgo...@redhat.com> wrote:
>>>> So it is a forgone conclusion that these new kernel changes to
>>>> crashkernel=X in 3.9 are incompatible with older kexec-tools and one
>>>> needs to upgrade kexec-tools.
>>>
>>> I thought that you and hpa all agreed that user need to update kexec-tools
>>> with
>>> new kernel v3.9. It that still right?
>>
>> I can update kexec-tools and I don't have problems with that. I am only
>> concerned about some xyz user complaining that new kernel stopped working
>> with old kexec-tools and then possibly face the rant from Linus about
>> breaking user space. :-)
>>
>> To me we could maintain backward compatibility by retaining the existing
>> behavior of crashkernle=X. That is look for specificied memory below
>> 896M first and then go higher.
>>
>> And hide new semantics behind new kernel parameters or by extending
>> existing parameter (say crashkernel=X:search_high_first) to specify how
>> to search for reserved memory.
>>
>> In both the cases we should probably retain the logic of auto reserving
>> low memory for software iotlb and let user opt out if there is no need.
>>
>> So we don't have a strong reason that why we should break existing
>> kexec-tools. So I would prefer not to break it.
>>
>> But I think this is hpa's decision.
>
> hpa,
>
> ping. Any thoughts on this?
Pardon me while I retch. The whole kdump dependency mess is making me
sick to my stomach.
The fundamental problem you have is that the user has to take an action
that doesn't make any sense, because there isn't any sane method to
backflow the requirements from the crashkernel to the command line.
The only way I can think how to deal with that in a sane way that
doesn't require that the user has to understand a whole bunch of things
about their system that no user should ever have to be burdened with is
to have the packaging system feed back information about the crashkernel
and kexec-tools that will be used. That interface probably needs
serious architecting.
I wouldn't object to crashkernel=<size>,<option>,<option>... being the
format for that and it has the plus that it doesn't break less. So
something like "crashkernel=800M,high" (:search_high_first is
inconsistent with other options and completely pointlessly wordy... this
isn't Multics, and the command line space is a limited resource) would
make sense.
However, I really strongly suggest you work on a mechanism to take the
information about the crashkernel and utilities that the kernel can't
know and feed it into the bootloader configuration. This can be as
simple as a set of scripts.
-hpa
--
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/
