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;
Date:   Fri, 4 Dec 2020 09:17:33 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Jiri Slaby <jirislaby@kernel.org>
Cc:     Jann Horn <jannh@google.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tty: Remove dead termiox code
Message-ID: <X8nwnXQKOYWBWBZ+@kroah.com>
References: <20201203020331.2394754-1-jannh@google.com>
 <5cca5126-60ba-d123-0f7d-47fdbac4c4db@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5cca5126-60ba-d123-0f7d-47fdbac4c4db@kernel.org>
Precedence: bulk

On Fri, Dec 04, 2020 at 08:22:41AM +0100, Jiri Slaby wrote:
> On 03. 12. 20, 3:03, Jann Horn wrote:
> > set_termiox() and the TCGETX handler bail out with -EINVAL immediately
> > if ->termiox is NULL, but there are no code paths that can set
> > ->termiox to a non-NULL pointer; and no such code paths seem to have
> > existed since the termiox mechanism was introduced back in
> > commit 1d65b4a088de ("tty: Add termiox") in v2.6.28.
> > Similarly, no driver actually implements .set_termiox; and it looks like
> > no driver ever has.
> 
> Nice!
> 
> > 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?  :)