Re: [PATCH 08/11] xfsprogs: replace obsolete memalign with posix_memalign

[Dave Chinner <david@fromorbit.com>]

On Tue, Aug 18, 2015 at 10:33:49AM +0200, Jan Tulak wrote:
> On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:
> > > I thought about it. However, with memalign from malloc marked obsolete
> > > (and with posix_memalign having guaranteed alignment restrictions [1]), I
> > > saw it better
> > > to use the posix variant everywhere.
> >
> > Putting a sane wrapper around an nasty library function is just
> > fine. The memalign wrapper makes sense from this perspective - even
> > gcc can't tell if variables passed to posix_memalign are correctly
> > initialised or not, whereas no such problems exist for memalign().
> >
> > > I could make a wrapper simulating the old memalign behaviour, but I don't
> > > think it would make sense.
> >
> > I think it makes more sense than using posix_memalign() everywhere
> > and then ignoring the return variable that tells you it failed...
> >
> > > I searched for this, but didn't find any reasonable answer:
> > > How long can be things in standard libraries marked obsolete before
> > > removing?
> >
> > With a wrapper, we don't care.
> >
> > > [1] man memalign:
> > >        On many systems there are alignment restrictions, for example, on
> > buf-
> > >        fers  used  for  direct  block  device  I/O.  POSIX specifies the
> > path-
> > >        conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is
> > needed.
> > >        Now one can use posix_memalign() to satisfy this requirement.
> > >
> > >        posix_memalign()  verifies  that  alignment  matches  the
> > requirements
> > >        detailed above.  memalign() may not check that the  alignment
> > argument
> > >        is correct.
> >
> > Yes, you can get it wrong with memalign. But we don't, because we
> > follow the rules for DIO buffer alignment and set it correctly.
> > Being able to directly control the alignment of the memory buffer is
> > a reason for using memalign() over posix_memalign(), not the other
> > way around.
> >
> 
> So a wrapper used on all platforms is an acceptable solution? All right,
> this explanation makes sense. I will change it that way. The only question
> I have now is whether to use posix_memalign on every platform, or whether to
> make it platform_memalign and use the old memalign inside for Linux.

No need for a wrapper on platforms that support memalign. We can add
a wrapper when and if memalign ever goes away (which, FWIW, will
break lots of code). Indeed, we alreadyhave these platform dependent
"wrappers":

include/darwin.h:#define memalign(a,sz) valloc(sz)
include/freebsd.h:#define memalign(a,sz)        valloc(sz)

The question now is - do we even need to change anything?

https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html

"The valloc() function allocates size bytes of memory and returns a
 pointer to the allocated memory.  The allocated memory is
 aligned on a page boundary"

Which means it does pretty exactly the same thing as
posix_memalign(), and so we don't need to change anything, right?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs