On Tue, Oct 29, 2013 at 10:36:36AM +0800, Dave Young wrote:
On 10/29/13 at 11:04am, Simon Horman wrote:
> On Mon, Oct 28, 2013 at 12:10:40PM -0400, Vivek Goyal wrote:
> > On Mon, Oct 28, 2013 at 10:51:19AM +0000, Matthew Garrett wrote:
> > > On Mon, Oct 28, 2013 at 06:45:32PM +0800, Dave Young wrote:
> > > > On 10/28/13 at 10:39am, Matthew Garrett wrote:
> > > > > On Mon, Oct 28, 2013 at 06:34:12PM +0800, Dave Young wrote:
> > > > > > On 10/28/13 at 10:12am, Matthew Garrett wrote:
> > > > > > > Right, but previously acpi_rsdp was passed
automatically and now it
> > > > > > > won't be?
> > > > > >
> > > > > > Yes, it was. I'm removing them in kexec-tools patches
for efi runtime support.
> > > > >
> > > > > If I upgrade kexec-tools and try to launch an old kernel, I now
need to
> > > > > add an extra parameter?
> > > >
> > > > Yes, it should work by passing the acpi_rsdp= via --append
> > >
> > > Yes, that's my point. You're breaking old configurations by
requiring
> > > the user to pass an additional argument.
> >
> > Yes this is a problem. Of course solution is easy by always passing
> > acpi_rsdp on command line. But in long term this is a problem. In the
> > sense, I am not sure how to cleanup the kexec-tools code as things improve.
> > Now we will support the EFI properly and still pass acpi_rsdp always in
> > an effort to matain backward compatibility.
> >
> > For a very long time kexec-tools were not automatically appending
> > acpi_rsdp and user were supposed to add it on command line. We were
> > carrying this change in kdump scripts and pushed this change into
> > kexec-tools. In hindsight, it looks like that hardcoding parameters
> > in kexec-tools is a bad idea. It is hard to get rid of them in future.
>
> I tend to agree. However, if the parameters end up being hard coded
> elsewhere, for example in widely used wrapper scripts, then I think that
> the same problem still exists. Just outside of kexec-tools itself.
Kernel has a rule of not breaking userspace, does kexec-tools also have
the policy? Maybe user or distribution carry that will be slight better
so upstream kexec code will be cleaner..
I'm not sure that we have had to make a policy decision with regards
to this. At least not recently. But yes, I think it should be a goal
of kexec-tools not to break its users.