From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DE54C43331 for ; Thu, 26 Mar 2020 12:51:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2F4720748 for ; Thu, 26 Mar 2020 12:51:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="M45IuHIJ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="WpMbSseO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2F4720748 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VbXBoXLA0g+zcMHw2iA6XGzut2dMWoHkYsCrYK06TjM=; b=M45IuHIJ1J0zPt /KU5zT4Jj/ItBpCBKNbfA5qC9KU+1q42YqxtP2M8VXCIy4vSIZIYswcwOVT3obYETuStoB05THoZf 5mVZZoRh9rn+xgvs05TBcGUT09zesHbNob6qShf+CrAcPa7cuvamCh/XADcIy5ZNMrV15nml282ok 7SdDOzuGr99vav1EEdFYo5nOy8eZCykqvJzt099sdiskPfimJEDfHeKrtuHOK6r1+YVmBgXQzrBl7 ohLZreglataKnx4MZHEMeBIgMiIo4C2qlbBfQn8dDzNSVNkpKdDuTIz5w7qsYkWDGB06xf5YviBQH 7rPVH+xFKG+bwr7d2OBA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jHRys-00023e-24; Thu, 26 Mar 2020 12:51:30 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jHRyo-00023L-6F for linux-arm-kernel@lists.infradead.org; Thu, 26 Mar 2020 12:51:27 +0000 Received: from coco.lan (ip5f5ad4d8.dynamic.kabel-deutschland.de [95.90.212.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6461B2073E; Thu, 26 Mar 2020 12:51:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585227085; bh=zIulOGTEwdI3hssRscSNydLZe2G+oeZ2jtg11vXXxa0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WpMbSseODo1E92lj7T40pAB2Wh74HRlkBa1JdDpsvagBvVQHLFLhCwDBinmDbKLLi i1Ta5Atlrk9FKaPsD49ihgxy3OqThb8sItMvY4phyKyO/8Zd0NGMZTqn73rwFxHAgo u2EV2sNSSV/qsPGJEVtONh5Uv2/xemv6KIEaDi7k= Date: Thu, 26 Mar 2020 13:51:13 +0100 From: Mauro Carvalho Chehab To: Laurent Pinchart Subject: Re: [PATCH 0/4] media Kconfig reorg - part 2 Message-ID: <20200326135113.73c257ba@coco.lan> In-Reply-To: <20200326101333.GH20581@pendragon.ideasonboard.com> References: <6fadc6ea-8512-03ba-da30-43c64d7562f6@collabora.com> <20200325223820.1c74aed3@coco.lan> <20200325221343.GW19171@pendragon.ideasonboard.com> <20200326092832.069a4d17@coco.lan> <20200326101333.GH20581@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200326_055126_274704_BFDAF413 X-CRM114-Status: GOOD ( 29.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Belloni , Sylwester Nawrocki , Michal Simek , "Lad, Prabhakar" , Pavel Machek , Fabio Estevam , devel@driverdev.osuosl.org, linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Chen-Yu Tsai , Krzysztof Kozlowski , Ludovic Desroches , Kukjin Kim , NXP Linux Team , Steve Longerbeam , Bingbu Cao , Tian Shu Qiu , Yong Zhi , Philipp Zabel , Sakari Ailus , Sascha Hauer , Maxime Ripard , Niklas =?UTF-8?B?U8O2ZGVybHVuZA==?= , Helen Koike , Yong Deng , Ezequiel Garcia , linux-arm-kernel@lists.infradead.org, Hyun Kwon , Heungjun Kim , Paul Kocialkowski , Kyungmin Park , Pengutronix Kernel Team , Greg Kroah-Hartman , Hans Verkuil , Linux Media Mailing List , Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Em Thu, 26 Mar 2020 12:13:33 +0200 Laurent Pinchart escreveu: > > > I'm not sure to follow you. Are you implying that this patch series, > > > which Helen has tested against a real user, not an experienced kernel > > > hacker, may make the configuration options more difficult for kernel > > > hackers, but improves the situation for users ? > > > > Come on, it is not harder for Kernel hackers. It is just different than > > what it used to be before the changes. > > Sorry, I didn't meant to say it would be more complex for me (I mostly > don't use menuconfig anyway, I edit the .config file manually :-)), but > I was reading your e-mail as implying that, and was wondering if it was > me misreading it. So, the new design will be less complex for you, as some dependencies were changed to be automatically set when a driver is selected (media controller and V4L2 subdev APIs) ;-) > > > At the above experience, at the > > very first time this Kernel hacker looked on it, it was able to figure > > out how to enable the driver. I bet that, if you now repeat the experiment > > with the same guy, he would be able to enable another driver a lot quicker. > > > > My view is that, with the option of either enable or disable the > > filtering mechanism, it will be easier for everybody: > > > > - Distro maintainers for PCs can just disable platform and > > test drivers, and keep the other drivers enabled; > > > > - An experienced Kernel hacker will disable the filter and select > > the needed drivers directly. > > > > - An user wanting to test a driver with new patches (or a new driver) > > use the filters to select the USB driver he needs (probably using the > > media_tree.git, in order to see only the media options). > > My personal view is that this makes things more complex, and more > complexity usually means less clarity. If we want to be serious about > the usability of our Kconfig menu, we should get real users involved in > the design, at least by testing it on them, and getting feedback. > Otherwise we'll just be a bunch of kernel developers sitting in our > ivory tower thinking we know better than our users what is good for > them. The entire thing started by a proposal to change, in a way that it would be make things easier for m2m developers but harder for normal users. My proposal is to keep both behaviors, with a menu that would allow switching between those two different behaviors. So, it should make both groups happy :-) Not much complexity added. It is the other way around: I took the time to do several Kconfig cleanups, in order to make the Kconfig files cleaner and better organized (both internally and visually). - I don't object getting feedback from real users, but if we're willing to use such feedback in a consistent way, we need to have a group of people that could statistically represent the diversity that we have with the people which builds their own kernels. > > See, for some random distro maintainer, new Kconfig symbols pops up > > every time. Enabling all of them is usually a very bad idea. So, a > > filtering mechanism that would, for example, hide test and skeleton > > drivers to be built is a very nice feat, as it means a lot less > > symbols for them to study and decide whether such new options should > > be enabled or not > > The fact that test drivers are not shipped by some distros is annoying > for developers ;-) But that's a very small minority, and out of topic. Yes, agreed. Things could be easier for us if we could ask people to use a test driver when reporting certain bugs. On the other hand, having a test driver shipped by default together with a production Kernel don't make any sense for most usages. It would just make the Kernel package bigger and would never be used by the vast majority of users. It would also mean more work for security people that would be trying to do OS hardening. Well, Fedora has a kernel-debug Kernel, meant to be used when someone finds an issue on production and may require extra stuff to debug the Kernel. IMHO, it makes a lot of sense to have those test drivers shipped there (perhaps packaged in separate, like on a kernel-debug-media-test rpm). Thanks, Mauro _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel