Messages in this thread | | | Subject | Re: [PATCH] tty: Remove dead termiox code | From | Jiri Slaby <> | Date | Fri, 4 Dec 2020 09:51:07 +0100 |
| |
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
| |