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]
Message-ID: <1339155706.25798.55.camel@x61.thuisdomein>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ