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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 08 Jun 2012 13:41:46 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] delete seven tty headers

On Fri, 2012-06-08 at 13:00 +0200, Jiri Slaby wrote:
> On 06/08/2012 10:56 AM, Paul Bolle wrote:
> > --- a/include/linux/Kbuild
> > +++ b/include/linux/Kbuild
> > @@ -84,7 +84,6 @@ header-y += capability.h
> >  header-y += capi.h
> >  header-y += cciss_defs.h
> >  header-y += cciss_ioctl.h
> > -header-y += cdk.h
> >  header-y += cdrom.h
> >  header-y += cgroupstats.h
> >  header-y += chio.h
> > @@ -93,7 +92,6 @@ header-y += cn_proc.h
> >  header-y += coda.h
> >  header-y += coda_psdev.h
> >  header-y += coff.h
> > -header-y += comstats.h
> >  header-y += connector.h
> >  header-y += const.h
> >  header-y += cramfs_fs.h
> 
> NACK for these two files. I rather prefer going through the
> deprecate-wait_years-delete path (removal of __KERNEL__ parts, if there
> are any, is OK). 

No, none of these headers have __KERNEL__ parts.

> 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). 

> The rest is OK to be removed.

Thanks,


Paul Bolle

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