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: <201206081403.16608.arnd@arndb.de>
Date:	Fri, 8 Jun 2012 14:03:16 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Jiri Slaby <jslaby@...e.cz>,
	"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 Friday 08 June 2012, Paul Bolle wrote:
> > I doubt there are any users at all, but we still should
> > gave them a chance to fix their builds (remove those #include's and
> > potentially used defined/structs) and not introduce a userspace build
> > breakage.
> 
> I guess I'm being naive here, but will userspace still end up with
> something usable on older kernels (ie, kernels that still used the
> various things provided by these headers)? And, even then, are there
> still stable kernels that could possibly have working drivers related to
> these two headers?
> 
> If so I'm fine with providing these headers some additional time. But
> then we should add a "#warning# to these two headers and add a related
> entry to Documentation/feature-removal-schedule.txt). 

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!

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.

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.

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

	Arnd
--
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/