Re: [PATCH] tty: Remove dead termiox code

[Jiri Slaby]

On 04. 12. 20, 9:36, Greg Kroah-Hartman wrote:
> On Fri, Dec 04, 2020 at 09:20:39AM +0100, Jiri Slaby wrote:
> > On 04. 12. 20, 9:17, Greg Kroah-Hartman wrote:
> > > 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.

Note this ^^^^^. He is talking about _not_ touching the definition in 
the UAPI header. Does the rest below makes more sense now?

> > > > 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?
>
> I'm sorry, but I don't understand.  This is a kernel-internal-only
> structure, right?  If someone today tries to call these ioctls, they
> will get a -EINVAL error as no serial driver in the tree supports them.
>
> If we remove the structure (i.e. what this patch does), and someone
> makes an ioctl call, they will still get the same -EINVAL error they did
> before.
>
> So nothing has changed as far as userspace can tell.
>
> Now if they have an out-of-tree serial driver that does implement this
> call, then yes, they will have problems, but that's not our problem,
> that is theirs for not ever submitting their code.  We don't support
> in-kernel apis with no in-kernel users.
>
> Or am I still confused?
>
> thanks,
>
> greg k-h


--
js