lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 8 Dec 2020 12:23:05 +0100 From: Jiri Slaby <jirislaby@...nel.org> To: Christoph Hellwig <hch@...radead.org> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jann Horn <jannh@...gle.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] tty: Remove dead termiox code On 08. 12. 20, 12:13, Christoph Hellwig wrote: > 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. OK, even better. I will remove it once I get to it (if noone beats me to it, of course). thanks, -- js suse labs
Powered by blists - more mailing lists