[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1524756256.3226.7.camel@HansenPartnership.com>
Date: Thu, 26 Apr 2018 08:24:16 -0700
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Michal Hocko <mhocko@...nel.org>,
David Rientjes <rientjes@...gle.com>, dm-devel@...hat.com,
eric.dumazet@...il.com, mst@...hat.com, netdev@...r.kernel.org,
jasowang@...hat.com, Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
linux-mm@...ck.org, edumazet@...gle.com,
Andrew Morton <akpm@...ux-foundation.org>,
virtualization@...ts.linux-foundation.org,
David Miller <davem@...emloft.net>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc
fallback options
On Thu, 2018-04-26 at 11:05 -0400, Mikulas Patocka wrote:
>
> On Thu, 26 Apr 2018, James Bottomley wrote:
[...]
> > Perhaps find out beforehand instead of insisting on an approach
> without
> > knowing. On openSUSE the grub config is built from the files in
> > /etc/grub.d/ so any package can add a kernel option (and various
> > conditions around activating it) simply by adding a new file.
>
> And then, different versions of the debug kernel will clash when
> attempting to create the same file.
Don't be silly ... there are many ways of coping with that in rpm/dpkg.
However, I take it the fact you're now trying to get me to explain
them means you take the point that a kernel dynamic option can be
activated in a variety of easy ways in a distribution including through
the boot menu; so if you want this to appear in the boot menu you don't
need a Kconfig option to achieve it.
> And what about other distributions? What about people who the RHEL
> kernel from source with "make"?
Well, if you build your own kernel and we have a dynamic option, it
will "just work" without you having to muck about trying to re-Kconfig
it, so I'd see that as a win.
> The problem with this approach that you are trying to bother more and
> more people with this little silly feature.
So you're shifting your argument from "I have to do it as a Kconfig
option because the distros require it" to "distributions will build
separate kernel packages for this, but won't do enabling in a non
kernel package"? To be honest, I think the argument is nuts but I
don't really care. From my point of view it's usually me explaining to
people how to debug stuff and "you have to build your own kernel with
this Kconfig option" compared to "add this to the kernel command line
and reboot" is much more effort for the debugger.
James
Powered by blists - more mailing lists