Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1673270ybl; Thu, 5 Dec 2019 05:21:00 -0800 (PST) X-Google-Smtp-Source: APXvYqw3c3zUsw90WfLINDxNE567I6iskOM86yQxNAZDkN2KkxFAtlotG0X1XYZ3olFNUsHX2Dwz X-Received: by 2002:a9d:5612:: with SMTP id e18mr6658009oti.183.1575552060202; Thu, 05 Dec 2019 05:21:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575552060; cv=none; d=google.com; s=arc-20160816; b=VzbbzQbCyBm2rVUmrFn01DWQ27Ie3NfUv5JnOuBlTIjtEjgBriEKr+x81m3qhDt/Io QgtIkWfuTUwZF7CzwgSGeVlKd4jvyd+O/iGp52fsBWWErlPOiRR1KFn2FtQ54TjDpFGf h0OabsxIPccAI8sVxuYS8DiqnrX5SVB7PftIW++qVpmHuM5T182PjFMz8WZt99DZcAOc DopgvtNT9c3//wnujra1uDCq3Ib6El3slWcgc1YvuzdpG76kkvji81JpkrX17pM/V1zq VVuYqqCuLE0Euxnmz4tb1buvBU5p7mbTO7ZlSJPI1dXPFuELmuveBlznvg8iuYDzWIZL UO3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=rwZxIii9b0mENkdP46oXy6e43rzsXBHH1ccw6K+57Uw=; b=zhlMHPhCAufpNz2SA/Yu2z9ws7JtWbNI8q8ofoaE2KDmRTLyoMxcQuA+O+7kjd13QB WKeHl5qLqupcjwdITEugXuiPjzWMOD7lbCvR57yq76WPbn0rqttdDLK98gcgm0SP5lbF tuHp6xXnk6gvFgwnQsSIOhB20dZSh+0mlD7cs1UA9ufondR8BgASJMI8TTGRfvHKhF5l GEpttCe6iRVuSKNdLiFEZkpZeI7QLqyW5vs6EBYo4rjVcNPyH1GcqIlI/B8lZtMjIl60 5c7eo3c8DFGWXZ84IWggLsaf6CnLYOlFpbZAR4Wj8//88XKQsJnim1sKF3WeIh/WUkAN I/Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20150623.gappssmtp.com header.s=20150623 header.b=sZ99D5hW; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l21si5039844oic.126.2019.12.05.05.20.46; Thu, 05 Dec 2019 05:21:00 -0800 (PST) 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=pass header.i=@brainfault-org.20150623.gappssmtp.com header.s=20150623 header.b=sZ99D5hW; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729577AbfLENUJ (ORCPT + 99 others); Thu, 5 Dec 2019 08:20:09 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:56148 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729099AbfLENUI (ORCPT ); Thu, 5 Dec 2019 08:20:08 -0500 Received: by mail-wm1-f67.google.com with SMTP id q9so3746133wmj.5 for ; Thu, 05 Dec 2019 05:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rwZxIii9b0mENkdP46oXy6e43rzsXBHH1ccw6K+57Uw=; b=sZ99D5hWKWNagSaF7mf1VWHrbnKL7ZW8yqyCfwzMzyTDIV87cQNd8QJNyZ3GAJJLGC +GXWWspSUiwg3M9hL8wqdtk6z7WG7pxpW5WXvS506faOCpMq08jt5yEnZEAjTP3QOEpM A+Qjwu5u6twz1c1scOFqkC0v3W/ZRHbdaZWCg8syPtvUWQ7oApA9Nvy6uR2+mT2lsnEU 7gFZoHw8TGQQpmn6B+6gqf8vvRmSxiRdoStSmbJGEQ6np7n14zLpUVY+hGz2PyGVUL7B SUBj9S/5GdZRbEYUbs3+WC8WgSOS7jFmmn3dPFuXXYSQeZWC3uCGLsS1bOw43/7Nu7qN Fmww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rwZxIii9b0mENkdP46oXy6e43rzsXBHH1ccw6K+57Uw=; b=G6BvxzkJ/cjb8SiweYAQBGJDxfgRu0k84x8naE8mpZwuu8WWqIzpoRROh3egkefPV0 OTegMhoewXGfe1xzcLBbNwKHGr2QB3Nxb/4RPYBYcZvsl92hOedLsNN7DAtBSkp+ZIMM fd4c74Th/XERimZhITUhD/zd87H7w+Y7eAjdnU4OYbKNndNglQqc+cwjw7IoIvDCRyMB Xnekwj4CrZiEAD4CC0akm1gq7X0SHnFHjHkRSKJ+74GcueNoqsTNZrSU2vPRUSL9jLYG wN/jkcbf+JZ+Wt0j+FdhkRNRiasRZzk0QXSDnNFW42UumdsueWIZuL7nPm7vpxQp6eh3 gerQ== X-Gm-Message-State: APjAAAWA3Sm3LSLvLcty9MAmCxF9/zdECQrmdCCPTBHy4R5351hLF71P jEFx9Y1d+E+uTeD4FNjZiv0Ovq6bx43TPFr5LWCnaQ== X-Received: by 2002:a1c:984f:: with SMTP id a76mr5086929wme.64.1575552004891; Thu, 05 Dec 2019 05:20:04 -0800 (PST) MIME-Version: 1.0 References: <9044bad02aa6553cdb2523294500b50fccf3fd2a.camel@wdc.com> <81530734312456aab8b9625d7e9bb071c43db1c5.camel@wdc.com> <84c4ee600c0dd235a0fcc257115807af7207b5f6.camel@wdc.com> In-Reply-To: From: Anup Patel Date: Thu, 5 Dec 2019 18:49:54 +0530 Message-ID: Subject: Re: [GIT PULL] Second set of RISC-V updates for v5.5-rc1 To: David Abdurachmanov Cc: Alistair Francis , "paul.walmsley@sifive.com" , "linux-kernel@vger.kernel.org" , Atish Patra , "linux-riscv@lists.infradead.org" , "torvalds@linux-foundation.org" , "hch@lst.de" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 5, 2019 at 11:06 AM David Abdurachmanov wrote: > > On Thu, Dec 5, 2019 at 5:58 AM Alistair Francis > wrote: > > > > On Wed, 2019-12-04 at 18:54 -0800, Paul Walmsley wrote: > > > On Wed, 4 Dec 2019, Alistair Francis wrote: > > > > > > > That is just not what happens though. > > > > > > > > It is too much to expect every distro to maintain a defconfig for > > > > RISC- > > > > V. > > > > > > The major Linux distributions maintain their own kernel > > > configuration > > > files, completely ignoring kernel defconfigs. This has been so for a > > > long > > > time. > > > > That might be true for the traditional "desktop" distros, but embedded > > distros (the main target for RISC-V at the moment) don't generally do > > this. > > I can confirm that Fedora/CentOS/RHEL do not depend on default > config in kernel. Same seems to apply to Ubuntu, Arch and probably > others. We maintain our own configs. Thanks for the confirmation. Unfortunately, this does not apply to Yocto and Buildroot (and there could be others too). > > > > > > > > > > Which is why we currently use the defconfig as a base and apply > > > > extra > > > > features that distro want on top. > > > > > > As you know, since you've worked on some of the distribution builder > > > frameworks (not distributions) like OE and Buildroot, those build > > > systems > > > have sophisticated kernel configuration patching and override systems > > > that > > > can disable the debug options if the maintainers think it's a good > > > idea to > > > do that. > > > > Yes they do. As I said, we start with the defconfig and then apply > > config changes on top. Every diversion is a maintainence burden so > > where possible we don't make any changed. All of the QEMU machines > > currently don't have config changes (and hopefully never will) as it's > > a pain to maintain. > > > > > > > > You've contributed to both Buildroot and OE meta-riscv RISC-V kernel > > > configuration fragments yourself, so this shouldn't be a problem for > > > you > > > if you disagree with our choices here. For example, here's an > > > example of > > > how to patch defconfig directives out in Buildroot: > > > > > > > > > https://git.buildroot.net/buildroot/tree/board/qemu/csky/linux-ck807.config.fragment#n3 > > > > > > I'm assuming you don't need an example for meta-riscv, since you've > > > already contributed RISC-V-related kernel configuration fragments to > > > that > > > repository. > > > > As I stated, this is possible. It's just a pain to maintain and for the > > QEMU machines will probably not happen. > > > > We are trying to remove RISC-V specific changes, not add more. > > > > > > > > > Expecting every distro to have a kernel developers level of > > > > knowledge > > > > about configuring Kconfigs is just unrealistic. > > > > > > I think it's false that only kernel developers know how to disable > > > debug > > > options in Kconfig files. As far as the underlying premise that one > > > shouldn't expect distribution maintainers to know how to change > > > Kconfig > > > options, we'll just have to agree to disagree. > > > > Do you really expect every disto to follow all of the kernel changes > > and generate their own config based on what happened in the kernel tree > > since the last release? We don't all just spend our days adjusting to > > the Linux kernel. > > I cannot talk for all distros (there are too many), but major desktop > distributions do that. For the 1st few RCs of a new kernel version I > will be adjusting Fedora/RISCV configuration based on whatever > changes land. > > Of course looking at default defconfig is part of that process. Yes, we cannot generalize that all distros use their own configs. Lot of embedded users prefer Yocto and Buildroot which certainly depend on Linux defconfigs. > > > > > This is espicially true for RISC-V as it's new and constantly changing. > > > > > > > > > > distros and benchmarkers will create their own Kconfigs for their > > > > > needs. > > > > > > > > Like I said, that isn't true. After this patch is applied (and it > > > > makes > > > > it to a release) all OE users will now have a slower RISC-V kernel. > > > > > > OE doesn't have any RISC-V support upstream, so pure OE users won't > > > notice > > > > That is just not true. You talk later about misinformation but this is > > a blatent lie. > > > > > any change at all. Assuming you're talking about meta-riscv users: > > > as > > > noted above, it's simple to automatically remove Kconfig entries you > > > disagree with, or add ones you want. > > > > > > > Now image some company wants to investigate using a RISC-V chip for > > > > their embedded project. They use OE/buildroot to build a quick test > > > > setup and boot Linux. It now runs significantly slower then some > > > > other > > > > architecture and they don't choose RISC-V. > > > > > > The best option for naive users who are seeking maximum performance > > > is to > > > use a vendor BSP. This goes beyond settings in a kernel config file: > > > it > > > extends to compiler and linker optimization flags, LTO, accelerator > > > firmware and libraries, non-upstreamed performance-related patches, > > > vendor support, etc. > > > > What? How many people actually do this for embedded systems. > > > > I agree that if you really want to maximise it as much as you can you > > will go to this effort, but I don't think most people do. I think we > > all know that lots of times embedded Linux is just hacked until it > > works and then shipped. In this case defaults are very important. > > > > > > > > > Slowing down all users to help kernel developers debug seems like > > > > the > > > > wrong direction. Kernel developers should know enough to be able to > > > > turn on the required configs, why does this need to be the default? > > > > > > It's clear you strongly disagree with the decision to do this. It's > > > certainly your right to do so. But it's not good to spread > > > misinformation > > > about how changing the defconfigs "slow[s] down all users," or > > > > What misinformation? > > > > Anup shared benchmarking results indicating that this change has a 12% > > performance decrease for everyone who uses the defconfig without > > removing this change. > > > > That is everyone who doesn't decide to remove config options from the > > default config supplied by the people who wrote the code are now stuck > > with a large performance hit. Passing the buck and saying that people > > should be changing the defconfig cannot be the right solution here. > > > > > exaggerating the difficulty for downstream software environments to > > > back > > > this change out if they wish. > > > > If you think it is that easy can you please submit the patches? > > > > I understand it's easy to make decisions that simplfy your flow, but > > this has real negative consequences in terms of performance for users > > or complexity for maintainers. It would be nice if you take other users > > /developers into account before merging changes. > > I would prefer to have a separate config for debug (that's what we do in That's what I had suggested in my first comment on Paul's patch but he did not respond. Unfortunately, we are having this conversation here after the patch was merged by Paul without any discussions. (Refer, https://lkml.org/lkml/2019/11/22/2084) I have also sent a follow-up patch to add debug defconfigs. (Refer, https://lkml.org/lkml/2019/12/4/1411) There are two major concerns here: 1. Linux development process not being followed Like I mentioned, I had already commented on Paul's patch. He simply ignored my concerns about performance impact. This is a bad trend being established in Linux RISC-V development. 2. Generalizing that all distros use their own config This generalization is not true for any architecture. In fact, there are lot of users (and distros) across architectures who depend on Linux defconfig for building kernel image. > Fedora). Why not use config fragment here (e.g. call it debug.config like > in powerpc)? This would be an interesting thing to explore if it benefits everyone but for now we need separate debug defconfigs. > > See: > https://github.com/torvalds/linux/commit/c1bc6f93f95970f917caaac544a374862e84df52 > https://elinux.org/images/3/39/Managing-Linux-Kernel-Configurations-with-Config-Fragments-Darren-Hart-VMware.pdf > Regards, Anup