Re: [PATCH 2/2 v4] [BZ #10283] localedef: align fixed maps to SHMLBA

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/19/2013 11:17 AM, Mike Frysinger wrote:
> On Tuesday 11 June 2013 13:40:23 Roland McGrath wrote:
>>> On Monday 03 June 2013 15:14:56 Roland McGrath wrote:
>>>>> +#include <sys/shm.h>
>>>>> +#define MAP_FIXED_ALIGNMENT SHMLBA
>>>>
>>>> This is the Linux-specific definition.  The generic file should just
>>>> use page size, or perhaps the macro should be defined such that the
>>>> code (or at least the compiler) can tell statically that there is no
>>>> need for additional operations at all when the requirement is no
>>>> larger than page size.
>>>
>>> in the discussion on this matter earlier, there were multiple points
>>> raised.  it isn't unique to Linux (at least Solaris does it), and if this
>>> generally the sane default, then having it be the generic default makes
>>> sense.  especially since it doesn't really hurt when it's larger, and
>>> it's safer.
>>
>> It is not as yet the specified GNU API.  I don't think it should be,
>> either.
> 
> if the hurd guys care, they can add their own that does whatever they need it 
> to.  this behavior wouldn't break them.
> 
> even then, nothing has changed for them.  the locale code today is explicitly 
> rounding to page sizes.  the default SHMLBA define does that too:
> bits/shm.h:#define SHMLBA       (__getpagesize ())
> 
> as well as the gnu header:
> sysdeps/gnu/bits/shm.h:#define SHMLBA       (__getpagesize ())
> 
> so with this new header in the place i'm proposing, the only targets that 
> generate different code are the few Linux arches that define SHMLBA larger than 
> getpagesize.
> 
> after all, the issue we're talking about here isn't really founded in the 
> Linux port, but from the hardware itself.  it arises due to aliasing issues 
> with hardware memory maps.  so i don't see how the hurd guys could even avoid 
> it if they ever get around to doing a port for sparc/arm/ia64/hppa/etc...

Agreed. We would face the same issues regardless of the OS and the solution
would be the same.

c.