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;
From:   "Bird, Tim" <Tim.Bird@sony.com>
To:     "josh@joshtriplett.org" <josh@joshtriplett.org>,
        Arnd Bergmann <arnd@arndb.de>
CC:     linux-arch <linux-arch@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: RE: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
Thread-Topic: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
Thread-Index: AQHWZ0tdFHgmKRoEqU+Vr8dgbGY8EakiNCiAgAAFxNA=
Date:   Fri, 31 Jul 2020 21:57:41 +0000
Message-ID: <CY4PR13MB1175A3B5D9DE33D3A1E045A6FD4E0@CY4PR13MB1175.namprd13.prod.outlook.com>
References: <CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com>
 <20200731212721.GC32670@localhost>
In-Reply-To: <20200731212721.GC32670@localhost>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 82ee0b16-f33b-42b4-d531-08d8359cbf54
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 21:57:41.3293
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 66c65d8a-9158-4521-a2d8-664963db48e4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: p6JrqXCjJMzfRhKHHPoYaUhX/J7LE1tbbi0du2YY3sXmv+KZeSG7F1NvlnwDEMcs/x6xw8OTBKcS8s2zLs9rzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1301MB2104
X-Sony-Outbound-GUID: LBasDos5cIa0nVEJPRIu0CT9TKezEDec
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687
 definitions=2020-07-31_09:2020-07-31,2020-07-31 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011
 priorityscore=1501 lowpriorityscore=0 phishscore=0 adultscore=0
 impostorscore=0 spamscore=0 bulkscore=0 mlxscore=0 malwarescore=0
 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2006250000 definitions=main-2007310153
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: josh@joshtriplett.org
>=20
> On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > The majority of the code in the kernel deals with hardware that was mad=
e
> > a long time ago, and we are regularly discussing which of those bits ar=
e
> > still needed. In some cases (e.g. 20+ year old RISC workstation support=
),
> > there are hobbyists that take care of maintainership despite there bein=
g
> > no commercial interest. In other cases (e.g. x.25 networking) it turned
> > out that there are very long-lived products that are actively supported
> > on new kernels.
> >
> > When I removed support for eight instruction set architectures in 2018,
> > those were the ones that no longer had any users of mainline kernels,
> > and removing them allowed later cleanup of cross-architecture code that
> > would have been much harder before.
> >
> > I propose adding a Documentation file that keeps track of any notable
> > kernel feature that could be classified as "obsolete", and listing
> > e.g. following properties:
> >
> > * Kconfig symbol controlling the feature
> >
> > * How long we expect to keep it as a minimum
> >
> > * Known use cases, or other reasons this needs to stay
> >
> > * Latest kernel in which it was known to have worked
> >
> > * Contact information for known users (mailing list, personal email)
> >
> > * Other features that may depend on this
> >
> > * Possible benefits of eventually removing it
>=20
> We had this once, in the form of feature-removal-schedule.txt. It was,
> itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
>=20
> I *do* think there'd be value in having policies and processes for "how
> do we carefully remove a driver/architecture/etc we think nobody cares
> about". That's separate from having an actual in-kernel list of "things
> we think we can remove".

I'm not sure the documents are the same.  I think what Arnd is proposing
is more of a "why is this thing still here?" document.  When someone does
research into who's still using a feature and why, that can be valuable inf=
ormation
to share so that future maintenance or removal decisions can be better info=
rmed.

Maybe e-mails are sufficient for this, but they'd be harder to find than so=
mething in
the kernel source. But that supposes that people would look at the file, wh=
ich=20
appears didn't happen with feature-removal-schedule.txt.

 -- Tim