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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C214CC4361B for ; Tue, 8 Dec 2020 11:14:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7DF6923A5E for ; Tue, 8 Dec 2020 11:14:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728994AbgLHLN4 (ORCPT ); Tue, 8 Dec 2020 06:13:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726993AbgLHLN4 (ORCPT ); Tue, 8 Dec 2020 06:13:56 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 080B4C061749 for ; Tue, 8 Dec 2020 03:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=k/YWMVCp8Xvx3iJ8GfgpbtQhrzfSCoGjWFcSc3nBKTw=; b=q/8ZULrvyCLiDe1nwkRE9hnW+2 n8njRcSwHSp1sMYWUaAzH6oKAPVpyzWV1shY2OieTVPGKyYAJLYa0QvsPXUPqoTX3K7W82wuKzcU7 casDcHJdE7hjdPaF3MMsVyXWt5t99jHMsaAfgBxyFz1jfunwQcVtrKjM8IkWIhbePbBaauncIQfRP Ck8CzSlj9ZVu+c7cI86Yz6ANnsIOA/rdvTBJP23FeDr0Cfnr2CkYgDr0tONhhpns7DZ4mHXTHpFDj kyRKcCjVDmsXHYDxfmS2Jh8EM9SLRE8gWtHN6GTIedKod1001ojr3MWkJ80ZfQ8nVmlRgeI9mAJuN XuvUSEwg==; Received: from hch by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmavg-0007Mn-E1; Tue, 08 Dec 2020 11:13:12 +0000 Date: Tue, 8 Dec 2020 11:13:12 +0000 From: Christoph Hellwig To: Jiri Slaby Cc: Greg Kroah-Hartman , Jann Horn , linux-kernel@vger.kernel.org Subject: Re: [PATCH] tty: Remove dead termiox code Message-ID: <20201208111312.GA27425@infradead.org> References: <20201203020331.2394754-1-jannh@google.com> <5cca5126-60ba-d123-0f7d-47fdbac4c4db@kernel.org> <93834a92-b342-aaee-c400-2883d5df0cdc@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93834a92-b342-aaee-c400-2883d5df0cdc@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 04, 2020 at 09:20:39AM +0100, Jiri Slaby wrote: > > > > Delete this dead code; but leave the definition of struct termiox in the > > > > UAPI headers intact. > > > > > > I am thinking -- can/should we mark the structure as deprecated so that > > > userspace stops using it eventually? > > > > If it doesn't do anything, how can userspace even use it today? :) > > Well, right. I am in favor to remove it, BUT: what if someone tries that > ioctl and bails out if EINVAL is returned. I mean: if they define a local > var of that struct type and pass it to the ioctl, we would break the build > by removing the struct completely. Even if the code didn't do anything > useful, it still could be built. So is this very potential breakage OK? Um, we do guarantee a stable ABI. We have never guaranteed that all old crappy code will continue to compile, although we avoid gratious breakage. And assuming there ever was code using termiox (which I'm not sure about to start with) it will surely have some form of feature check, and I think we are better off with that feature check not detecting the presence as that would be completely pointless. Or in short: by keeping the uapi definition we do userspace software a disfavor.