[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210324225812.GM77072@balbir-desktop>
Date: Thu, 25 Mar 2021 09:58:12 +1100
From: Balbir Singh <bsingharora@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
"Alexander A. Klimov" <grandmaster@...klimov.de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Andrew Lunn <andrew@...n.ch>,
Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>,
Arnd Bergmann <arnd@...db.de>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Brian Cain <bcain@...eaurora.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Chris Zankel <chris@...kel.net>,
Corentin Labbe <clabbe@...libre.com>,
"David S. Miller" <davem@...emloft.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
Greentime Hu <green.hu@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Gregory Clement <gregory.clement@...tlin.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Helge Deller <deller@....de>, Hillf Danton <hdanton@...a.com>,
huang ying <huang.ying.caritas@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
James Troup <james.troup@...onical.com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Jonas Bonn <jonas@...thpole.se>,
Jonathan Corbet <corbet@....net>,
Kairui Song <kasong@...hat.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux API <linux-api@...r.kernel.org>,
Liviu Dudau <liviu.dudau@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Luis Chamberlain <mcgrof@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Matt Turner <mattst88@...il.com>,
Max Filippov <jcmvbkbc@...il.com>,
Michael Ellerman <mpe@...erman.id.au>,
Michal Hocko <mhocko@...e.com>,
Mike Rapoport <rppt@...nel.org>,
Mikulas Patocka <mpatocka@...hat.com>,
Minchan Kim <minchan@...nel.org>,
Niklas Schnelle <schnelle@...ux.ibm.com>,
Oleksiy Avramchenko <oleksiy.avramchenko@...ymobile.com>,
Palmer Dabbelt <palmerdabbelt@...gle.com>,
Paul Mackerras <paulus@...ba.org>,
"Pavel Machek (CIP)" <pavel@...x.de>, Pavel Machek <pavel@....cz>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Pierre Morel <pmorel@...ux.ibm.com>,
Randy Dunlap <rdunlap@...radead.org>,
Richard Henderson <rth@...ddle.net>,
Rich Felker <dalias@...c.org>,
Robert Richter <rric@...nel.org>,
Rob Herring <robh@...nel.org>,
Russell King <linux@...linux.org.uk>,
Sam Ravnborg <sam@...nborg.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Stafford Horne <shorne@...il.com>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
Steven Rostedt <rostedt@...dmis.org>,
Sudeep Holla <sudeep.holla@....com>,
Theodore Dubois <tblodt@...oud.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Thomas Gleixner <tglx@...utronix.de>,
Vasily Gorbik <gor@...ux.ibm.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
William Cohen <wcohen@...hat.com>,
Xiaoming Ni <nixiaoming@...wei.com>,
Yoshinori Sato <ysato@...rs.osdn.me>
Subject: Re: [PATCH v1 0/3] drivers/char: remove /dev/kmem for good
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@...ces 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.
Balbir Singh
Powered by blists - more mailing lists