Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp136261pxf; Wed, 24 Mar 2021 23:50:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZocmmm2qSBMnl8U3eETx4Lwlzsyhb29Th8fU+3t3V93vRQ9z8JlPiwOO3naoPT4UkQs73 X-Received: by 2002:a50:fe08:: with SMTP id f8mr7253905edt.217.1616655024053; Wed, 24 Mar 2021 23:50:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616655024; cv=none; d=google.com; s=arc-20160816; b=PGNd+tF5fqUXBsY7SoLJPJe/dBkU9yWPtMGoYvohWLPec7HxfExEYWumgFRn4OSayr LkvrTEjhp9hImehKocvs9WkPAzfFlFbIyrO4huk3YDQ2iff7NI5YzB4oi+EU3H5S+E5T 6kgB1cnq5YZURqv/vEPJgRx87kK2plZ+YkoEB7/DwF8d0k5J+MyIA7keq83n/kGTIAqJ lWZgvxjPfJV3kxTVWddumHmP8g+eyphqy8AW0VqGl5YO6x1uiMnov1DzArJkGOs2HpBY ILLyWHeMJ3oLVrywY/5MVsxBu0B+Pzyke48TMgIC3UeBS0VETO1wqCBC40s3oOy1TV8K 3zYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9C35z3nsO4GVicgZRpoemlkOpeo9/yq/XAv5Pji4gWI=; b=vlCqrJET0zdPO8HtYi+0dmqydAEBw5fqgI7DTK8FARw/Ogbi07yNZLW33lyACt1nCV ylv/3zhWjmYaV6ByICjf/7bgjibs78wh2kJ3E498+ulfuIYJWOFTjwFnfPd2z17E90pi T4IqSE4Js2ZPSLcoIuPyZyzbr+viO2v31UThalRvq45OVUIKgW4N7XCsE3QmMN4yc0JP QivIULMJdnt78UcvGt8jn4dk6imc1+XYS0jjkH5RMnH49L9ea28akb2FxiegZ2neqPlE aGLraMpo2hmuA/YxKwg+SEKcTKvDCx+dgmU3VNec1N5gQeTk0llApHJXXCG2yM5GM5KJ x/xg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LV0L2HrW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o13si3809384edi.135.2021.03.24.23.50.01; Wed, 24 Mar 2021 23:50:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LV0L2HrW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229590AbhCYGqx (ORCPT + 99 others); Thu, 25 Mar 2021 02:46:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:57954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbhCYGqW (ORCPT ); Thu, 25 Mar 2021 02:46:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 092D96196C; Thu, 25 Mar 2021 06:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1616654781; bh=/bWXfIbKchosJuds3GtGSYe3Fmxl28hRKZ2NNwbgsZ0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LV0L2HrWiWFSQLHQ9K2y3ZiXOdKtS5f7XaIhNmZGREHfokELU4V3/XChxSfTzu8n+ TQGKJ0OU/awi/NXK/7Iq+cyA3dBNW3dDeOOq5KE8YAWsINkQ1FN26ZKKxjo4aaNlVZ elF+ZLYttYpavKZffZAlo0a/8bAHO4qKFk7gLrcs= Date: Thu, 25 Mar 2021 07:46:17 +0100 From: Greg Kroah-Hartman To: Balbir Singh Cc: Andrew Morton , David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Alexander A. Klimov" , Alexander Viro , Alexandre Belloni , Andrew Lunn , Andrey Zhizhikin , Arnd Bergmann , Benjamin Herrenschmidt , Brian Cain , Christian Borntraeger , Christophe Leroy , Chris Zankel , Corentin Labbe , "David S. Miller" , "Eric W. Biederman" , Geert Uytterhoeven , Gerald Schaefer , Greentime Hu , Gregory Clement , Heiko Carstens , Helge Deller , Hillf Danton , huang ying , Ingo Molnar , Ivan Kokshaysky , "James E.J. Bottomley" , James Troup , Jiaxun Yang , Jonas Bonn , Jonathan Corbet , Kairui Song , Krzysztof Kozlowski , Kuninori Morimoto , Linus Torvalds , Linux API , Liviu Dudau , Lorenzo Pieralisi , Luc Van Oostenryck , Luis Chamberlain , Matthew Wilcox , Matt Turner , Max Filippov , Michael Ellerman , Michal Hocko , Mike Rapoport , Mikulas Patocka , Minchan Kim , Niklas Schnelle , Oleksiy Avramchenko , Palmer Dabbelt , Paul Mackerras , "Pavel Machek (CIP)" , Pavel Machek , "Peter Zijlstra (Intel)" , Pierre Morel , Randy Dunlap , Richard Henderson , Rich Felker , Robert Richter , Rob Herring , Russell King , Sam Ravnborg , Sebastian Andrzej Siewior , Sebastian Hesselbarth , Stafford Horne , Stefan Kristiansson , Steven Rostedt , Sudeep Holla , Theodore Dubois , Thomas Bogendoerfer , Thomas Gleixner , Vasily Gorbik , Viresh Kumar , William Cohen , Xiaoming Ni , Yoshinori Sato Subject: Re: [PATCH v1 0/3] drivers/char: remove /dev/kmem for good Message-ID: References: <20210324102351.6932-1-david@redhat.com> <20210324122412.e77247e6d3259d5493951019@linux-foundation.org> <20210324225812.GM77072@balbir-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210324225812.GM77072@balbir-desktop> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 25, 2021 at 09:58:12AM +1100, Balbir Singh wrote: > On Wed, Mar 24, 2021 at 12:24:12PM -0700, Andrew Morton wrote: > > > > > Let's remove /dev/kmem, which is unused and obsolete. > > > > I grabbed these. Silently - the cc list is amazing ;) > > > > I was wondering if it would be better to permanently disable /dev/kmem > > in Kconfig along with a comment "if you really want this thing then > > email peeps@places with a very good reason why". Let that ride for a > > year or three then blam. > > > > But this is so much more attractive, and it certainly sounds like it's > > worth any damage it might cause. > > > > We do tend to think about distros. I bet there are a number of weird > > embedded type systems using /dev/kmem - it's amazing what sorts of > > hacks those people will put up with the get something out the door. > > But those systems tend to carry a lot of specialized changes anyway, so > > they can just add "revert David's patch" to their pile. > > > > > I wonder if we should have the opposite of driver/staging and call it > outgoing, with a big thank you to the users and developers and also > to indicate this feature will be removed in the next (few) merge(s) > cycles. I guess not all code can be accumulated under a single > hierarchy. May not be worth the effort, just thinking out loud. That is exactly what drivers/staging/ is being used for, for stuff on the way out of the kernel. wimax just left the kernel that way a week or so ago, we've been doing this for many years now, the fact that no one has noticed is good as that means that no one has needed the code removed that way :) thanks, greg k-h