> * Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> > Borislav,
> >
> > On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > > On Mon, Oct 05, 2015 at 02:03:58AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > That's different from my point of view. I'm not going to pass
> > > > some data from the first kernel to the second kernel. I'm just going to
> > > > provide a configurable option for the second kernel to users.
> > >
> > > Dude, WTF?! You're adding a kernel command line which is supposed to
> > > be used *only* by the kdump kernel. But nooo, it is there in the open
> > > and visible to people. And anyone can type it in during boot. AND THAT
> > > SHOULDN'T BE POSSIBLE IN THE FIRST PLACE!
> > >
> > > This information is strictly for the kdump kernel - it shouldn't be a
> > > generic command line option. How hard it is to understand that simple
> > > fact?!
> >
> > Calm down!
> >
> > Disabling that NMI in the first kernel is not going to make the world
> > explode. We have enough command line options a user can type in, which
> > are way worse than that one. If some "expert" types nonsense on the
> > first kernel command line, then it's none of our problems, really.
> >
> > If Kawai would have marked that option as a debug feature, this
> > discussion would have probably never happened.
> >
> > Aside of that, the best way to hand in options for the kdump kernel is
> > the command line. We have an existing interface for that.
> >
> > Let's move on. Nothing to see here.
>
> So Boris kind of has a point: there are numerous problems with boot options as
> kexec parameter interface:
>
> - boot option strings are not a well defined programmatic interface:
> - failures are not obvious (they are often ignored)
> - inserting/setting parameters is awkward as well.
>
> - boot options are not an ABI, so when options have dual use with kexec it's easy
> to break things inadvertently: without that failure being apparent other than
> reintroducing obscure kexec failure modes again.
>
> - in the booted up kexec kernel it's not really obvious which options got set by
> kexec and which got set by the user - as there's no separation of namespaces.
>
> - likewise, if the user specifies an option in conflict with a kexec requirement
> it's not really obvious what's happening: the user setting should probably
> dominate - I'm not sure that's the case with the current kexec code.
Thanks for the detailed explanation. I can understand the disadvantages
of using boot option. So these are essential problems with boot options
rather than new boot option added for kexec'ed kernel.
> Boot options are basically a user interface.
>
> On the other hand the hack of (ab-)using boot parameters as kexec parameter
> passing is an existing, many years old practice and we cannot just stop it without
> offering an alternative (and better!) interface first.
>
> We could improve things by either adding a separate kexec-only parameter passing
> facility (like programmatic boot parameters are) - or by creating some sort of
> boot parameter alias that clearly identifies kexec parameters.
>
> So for example when introducing 'noextnmi' we'd also add a facility to add a
> 'kexec_noextnmi' alias - which clearly identifies this boot parameter as a kexec
> related one.
>
> Every 'kexec' inserted parameter would be prefixed by kexec_ - and then the
> separation of namespaces (and the prioritization of user vs. kexec requirements)
> becomes well defined as well..
>
> We should also probably print a warning if a kexec_* parameter is passed in that
> has no matching handler in the kexec()-ed kernel.
It would be reasonable. Or we might improve kexec command so that
it removes conflict boot options with warnings.
As I stated in another mail, I'm going to change "noextnmi" to
"apic_extnmi={bsp|all|none}", which can be used both the first and
second kernels. So, I'll add this option without "kexec_" prefix
at this point.
> I do concur that this patch is probably OK given existing practices.
Thanks!
--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
