public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Bolle <pebolle@tiscali.nl>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] delete seven tty headers
Date: Mon, 11 Jun 2012 14:42:32 +0200	[thread overview]
Message-ID: <4FD5E7B8.1020502@suse.cz> (raw)
In-Reply-To: <201206081403.16608.arnd@arndb.de>

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



  reply	other threads:[~2012-06-11 12:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08  8:56 [PATCH] delete seven tty headers Paul Bolle
2012-06-08  9:19 ` Alan Cox
2012-06-08 11:00 ` Jiri Slaby
2012-06-08 11:41   ` Paul Bolle
2012-06-08 14:03     ` Arnd Bergmann
2012-06-11 12:42       ` Jiri Slaby [this message]
2012-06-11 12:53         ` Alan Cox
2012-06-11 23:40           ` Greg Kroah-Hartman
2012-06-11 23:42             ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD5E7B8.1020502@suse.cz \
    --to=jslaby@suse.cz \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pebolle@tiscali.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox