linux-kernel - Re: [PATCH] delete seven tty headers

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FD5E7B8.1020502@suse.cz>
Date:	Mon, 11 Jun 2012 14:42:32 +0200
From:	Jiri Slaby <jslaby@...e.cz>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Paul Bolle <pebolle@...cali.nl>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] delete seven tty headers

On 06/08/2012 04:03 PM, Arnd Bergmann wrote:
> I think we should just apply the patches the way you sent them. We are
> in the much stricter about binary compatibility than about source level
> compatibility, and we already broke any potential user space applications
> that might be using these headers by removing the drivers implementing
> the kernel side of them, after deciding that they were unused!

Yes, but this patch is about breaking builds of toolkits. Some of the
tools from such toolkits still might work without the removed drivers.

> Building user space code against new kernel headers to run on old
> kernels is not really supported, because that might rely on new interfaces
> to be present. The only reason to keep the headers around would be to
> keep broken user space code building. I would not expect such code to
> still exist for the two header files, and if it does, then giving
> it an extra six months before it needs to be fixed is not going to
> make much of a difference.

I agree (I wrote I doubt there are any users at all). But I would prefer
going through the deprecation phase (adding a #warning) anyway. Removing
the headers completely in a year, or maybe sooner is OK then.

> OTOH, if it turns out that a modern distro still contains a package
> that relies on these headers, I would advocate putting a minimal
> header file with a #warning back into the kernel.

I think this is too late. Distros would find this out after months and
there will be no reason to re-add empty headers and backport them to
stable trees in between at that time...

> The only reference I could find on the internet to the ioctl commands
> that are getting removed is in the FreeBSD "stallion" user space,
> and they ditched the driver four years ago:
> http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173526.html

I wish google codesearch was not abandoned...

thanks,
-- 
js
suse labs


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/