All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Eric Blake <eblake@redhat.com>
Cc: "Christopher Covington" <cov@codeaurora.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] build: include sys/sysmacros.h for major() and minor()
Date: Fri, 30 Dec 2016 11:35:11 +0000	[thread overview]
Message-ID: <CAFEAcA_VN3QS-JnuBML+x+OZBR6c43ZPTko4kQfsvjRTvbWofA@mail.gmail.com> (raw)
In-Reply-To: <49b66510-1c3f-64fa-c0b0-125547bed7ca@redhat.com>

On 29 December 2016 at 13:48, Eric Blake <eblake@redhat.com> wrote:
> On 12/28/2016 11:07 AM, Peter Maydell wrote:
>> Also this seems straightforwardly like a bug in glibc: it shouldn't
>> be making this kind of breaking change. makedev(3) on my Linux box
>> says nothing about needing sysmacros.h for these.
>
> Here's the bug explaining the rationale behind the change:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=19239
>
> It IS a bug fix, but in the other direction - it is fixing namespace
> pollution that was present in <sys/types.h> and breaking certain
> standard-required idioms.  There HAS been warning, but system man pages
> have not always been updated to track upstream development, and the plan
> was that glibc 2.25 only causes a warning rather than outright failure
> to compile (although with -Werror, you have to adjust right away, rather
> than when the future glibc actually changes <sys/types.h> again to
> completely drop the pollution).
>
> It is CORRECT to fix any software relying on makedev() to use the
> CORRECT headers for that declaration, rather than getting it for free
> from <sys/types.h> pollution - the problem is that makedev() is not
> portable, and therefore the spelling of the correct header is not
> trivial - it requires some configure-time probing.

I checked a FreeBSD manpage and they don't put these macros
in sysmacros.h, they're in sys/types.h. I think the "correct"
header for them is sys/types.h, because that's where they've
always lived and where they've been documented to be. Otherwise
you're breaking API compatibility.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/include/sys/types.h
shows that sys/types.h is where these macros have lived
way back to 2.9BSD in 1983.

If POSIX requires sys/types.h not to provide these macros
then I think you could argue that that's a bug in the POSIX spec,
because it wasn't supposed to make major existing
implementations like the BSD family non-compliant.

For glibc to move to putting these macros somewhere weird
and different to everything else that implements them
is just forcing all programs that use them to add extra
configure machinery and ifdefs for no good reason.
QEMU now has to work around this glibc infelicity, of
course, but it would be better if it didn't have to.

Breaking existing code that was following the docs
is a big deal, and glibc should basically never do
it in my view.

thanks
-- PMM

  reply	other threads:[~2016-12-30 11:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 20:56 [Qemu-devel] [PATCH] build: handle deprecation of major() in sys/types.h Radim Krčmář
2016-09-22 21:09 ` Marc-André Lureau
2016-12-28 14:53   ` [Qemu-devel] [PATCH v2] build: include sys/sysmacros.h for major() and minor() Christopher Covington
2016-12-28 16:10     ` Eric Blake
2016-12-28 17:07       ` Peter Maydell
2016-12-29 13:48         ` Eric Blake
2016-12-30 11:35           ` Peter Maydell [this message]
2016-12-28 20:03       ` Christopher Covington
2016-12-28 20:04     ` [Qemu-devel] [PATCH v3] " Christopher Covington
2016-12-29 14:03       ` Eric Blake
2017-03-13 18:31         ` Eric Blake
2017-03-14 10:12       ` Peter Maydell
2016-09-22 21:09 ` [Qemu-devel] [PATCH] build: handle deprecation of major() in sys/types.h Eric Blake
2016-09-22 21:10 ` no-reply

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=CAFEAcA_VN3QS-JnuBML+x+OZBR6c43ZPTko4kQfsvjRTvbWofA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=eblake@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.