Re: RFC: deprecate sys/sysmacros.h inclusion from sys/types.h

[Mike Frysinger <vapier at gentoo dot org>]

On 18 Nov 2015 23:13, Zack Weinberg wrote:
> Andreas may still be running whole-distro rebuild tests, but enough
> results came back that I feel fairly confident saying that option B
> (remove the #include <sys/types.h> from stdlib.h) is a non-starter.
> There are too many (sloppily coded, yes) programs that include stdlib.h
> and expect it to expose all the POSIX foo_t types.  That leaves us with
> option A (remove the #include <sys/sysmacros.h> from sys/types.h) and
> even that is going to break stuff.  So we need a deprecation period.
> 
> The attached, lightly tested, patch sets up that deprecation period.
> From an application's perspective, it works like this:
> 
> * If you include <sys/sysmacros.h> directly, you get major(), minor(),
> and makedev() macros and everything works as it did before, regardless
> of whether you also include <sys/types.h> and in what order.
> 
> * If you define _SYS_TYPES_NO_SYSMACROS before including any headers,
> then <sys/types.h> does not include <sys/sysmacros.h> at all.
> 
> * If you include <sys/types.h>, you don't include <sys/sysmacros.h>, and
> you don't define _SYS_TYPES_NO_SYSMACROS, then you still get major(),
> minor(), and makedev() macros, but they trigger a deprecation warning if
> you *use* them.  This warning contains a lengthy explanation of what is
> about to change and suggests either including <sys/sysmacros.h> or
> defining _SYS_TYPES_NO_SYSMACROS, depending on whether you actually
> wanted the dev_t manipulators.
> 
> The implementation of all that is regrettably messy, but it works.  I
> also took the opportunity to genericize some of the code involved;
> sys/sysmacros.h and makedev.c both now live in misc/ instead of
> sysdeps/, and there's a new 'bits' header that encapsulates the only
> thing that varies between Linux and non-, which is the actual encoding
> of a dev_t.  (I'd appreciate extra-careful review of the arithmetic in
> the new bits headers; I'm not sure it was ever 100% correct, I may have
> messed it up, and there don't seem to be any tests.)
> 
> I deliberately didn't say "in the next release" in the deprecation
> message, because we might want to give this more than one cycle to bake.

shall we move forward with this ?  i've been sending patches to upstreams
and they've been taking them.
-mike

Attachment: signature.asc
Description: Digital signature