Received: by 10.192.165.148 with SMTP id m20csp2274973imm; Thu, 26 Apr 2018 08:25:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/24xM43pFhivfNlQxlYOfldOC7X2OLeIR21CJ0bnebmElMbD3krKd8sb/drTFfraNoYY9w X-Received: by 10.99.95.13 with SMTP id t13mr28446786pgb.145.1524756335307; Thu, 26 Apr 2018 08:25:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524756335; cv=none; d=google.com; s=arc-20160816; b=nNaj4GD6SkMpK69EHHHlj7TBlVosjSl45bsGVi8JWQuUNWp6yvmiIzhcbRZLrzNFqd rVQ68qNsoZoFBihejppZg7oHipn1MXxKX8NKb008GT14kyDqzCRf8dQw6Y0eg5Eon+9N WUsg5I3yd+xwNdMkOBkvzdurV5o/hL1QMkn/EywcyS4hLkpoRrDIOGgKeK4DUOXihtDi EBlSZ1nG2DVn/R3b5ZiWDIbr8z4RI2O02suzMmHTGukSRHJmQ423lzGckvseQ+oKy/JI 9nqqEA3/Ex3iDz7xXqYXSysiNz3r7pjQSu2BwOSBGBScpN6incMyBUuF0azmIjgwwJOP VXdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=x04Xy+clmiy9o7t+sBvE+0MA9R6hzD4Lv193lT63KSo=; b=vMWYoyDUn+MX4yWrJ0THwEC7BxjtYcJ3COCjPZquxicgmfrVyA4iA2/zDqFQubOqDj gjLVNBqJySBv3w/5DFRbWw45hLnmkbVGxvrOKoaIJ/Uxf2IICyJ1AkOogS97GkaSLqaH pUc7UBJ+au/Np9crVkSR8krotyKj8YQHYc9od1Y0wMe36oCHhthQQrNYPraGQ+dTf+TC FElGKOL9TjG2zqbtzpK70h0Ru81tYcSsp7TW87N48JRPRGQzV0wgELVk9tQnzPuVBscS X7R4P1DtcjstinmjxosCsvdR0IK0l5a1SF6PucVVnKAvV6T4PYiPB6h8xSTGazz4tszL 4zaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=Kf/HOJwl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3-v6si7192660pli.0.2018.04.26.08.25.18; Thu, 26 Apr 2018 08:25:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=Kf/HOJwl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756670AbeDZPYV (ORCPT + 99 others); Thu, 26 Apr 2018 11:24:21 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:50680 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756262AbeDZPYT (ORCPT ); Thu, 26 Apr 2018 11:24:19 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 858B38EE264; Thu, 26 Apr 2018 08:24:18 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Lo4BGhtLDE; Thu, 26 Apr 2018 08:24:18 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.65.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 770698EE0DC; Thu, 26 Apr 2018 08:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1524756258; bh=QPEuKpQITGB/LpyCE8sQZJT5FiHmA+H59FeDL/QFTiM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Kf/HOJwl6SURcUMQap8uVfZokf8VLSS15p2ksPr0nPNW3HNlmG2duyaMLk+JtSsf+ pof7N+ksC6ZDQj9hG9x2JvAisENXXeipP+bua1ydMuzATPnySiq5W3yFXvFqC1+OLZ 33cRbhcaANkhGyKyNfD/ydN1dHnmQJX2eWQhlsnk= Message-ID: <1524756256.3226.7.camel@HansenPartnership.com> Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options From: James Bottomley To: Mikulas Patocka Cc: Michal Hocko , David Rientjes , dm-devel@redhat.com, eric.dumazet@gmail.com, mst@redhat.com, netdev@vger.kernel.org, jasowang@redhat.com, Randy Dunlap , linux-kernel@vger.kernel.org, Matthew Wilcox , linux-mm@kvack.org, edumazet@google.com, Andrew Morton , virtualization@lists.linux-foundation.org, David Miller , Vlastimil Babka Date: Thu, 26 Apr 2018 08:24:16 -0700 In-Reply-To: References: <20180424170349.GQ17484@dhcp22.suse.cz> <20180424173836.GR17484@dhcp22.suse.cz> <1114eda5-9b1f-4db8-2090-556b4a37c532@infradead.org> <1524694663.4100.21.camel@HansenPartnership.com> <20180426125817.GO17484@dhcp22.suse.cz> <1524753932.3226.5.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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