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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ