All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf-kv+TWInifGbQT0dZR+AlfA@public.gmane.org>
To: Carlos O'Donell <carlos-v2tUB8YBRSi3e3T8WW9gsA@public.gmane.org>
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	james.bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org
Subject: Re: [RFC] Preventing overlap between arch mman.h and asm-generic/mman.h
Date: Tue, 27 Nov 2012 14:18:27 -0500	[thread overview]
Message-ID: <50B51203.3050009@tilera.com> (raw)
In-Reply-To: <20121121204238.GA9125@lazarus>

On 11/21/2012 3:42 PM, Carlos O'Donell wrote:
> David,
>
> Thanks for the great UAPI work. While working on glibc mman.h sync I had
> the chance to look more closely at some of the UAPI headers.
>
> Currently (3.7.0-rc6) sparc, powerpc, and tile are including mman-common.h,
> but nothing in mman-common.h helps prevent the accidental definition of an
> overlapping new constant value.
>
> For example in mman.h powerpc defines:
>  #define MAP_NORESERVE  0x40            /* don't reserve swap pages */
>  #define MAP_LOCKED     0x80
>
> If someone were to add a new MAP_* value in mman-common.h at 0x40 it
> would conflict with the existing powerpc value. The powerpc maintainers
> might not notice, and that's a bug.
>
> I notice that someone is trying to avoid this kind of bug, because for
> example the new MADV_HWPOISON was chosen as 100, which is higher than
> any other MADV_* value for any architecture.
>
> Rather than avoid the problem by spot-checking, would it be acceptable
> to merge in some private macros that block out exactly which constants
> are already in use as existing values for arches using UAPI headers?
>
> Doing it this way would allow for the merged arches to more safely
> include the asm-generic version of mman.h and start benefiting from new
> constants without the usual maintenance cost (not to mention everyone
> would start in lock-step going forward). Not to mention it simplifies
> some of the glibc maintenance.

This proposal looks reasonable to me and the proposed code seems OK for
tile, at least.  Thanks!

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

      reply	other threads:[~2012-11-27 19:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-21 20:42 [RFC] Preventing overlap between arch mman.h and asm-generic/mman.h Carlos O'Donell
2012-11-27 19:18 ` Chris Metcalf [this message]

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=50B51203.3050009@tilera.com \
    --to=cmetcalf-kv+twinifgbqt0dzr+alfa@public.gmane.org \
    --cc=carlos-v2tUB8YBRSi3e3T8WW9gsA@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=james.bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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.