<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 19, 2015 at 12:01 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Tue, Aug 18, 2015 at 10:33:49AM +0200, Jan Tulak wrote:<br>
> On Tue, Aug 18, 2015 at 10:20 AM, Dave Chinner <<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>> wrote:<br>
><br>
> > On Tue, Aug 18, 2015 at 09:04:24AM +0200, Jan Tulak wrote:<br>
> > > I thought about it. However, with memalign from malloc marked obsolete<br>
> > > (and with posix_memalign having guaranteed alignment restrictions [1]), I<br>
> > > saw it better<br>
> > > to use the posix variant everywhere.<br>
> ><br>
> > Putting a sane wrapper around an nasty library function is just<br>
> > fine. The memalign wrapper makes sense from this perspective - even<br>
> > gcc can't tell if variables passed to posix_memalign are correctly<br>
> > initialised or not, whereas no such problems exist for memalign().<br>
> ><br>
> > > I could make a wrapper simulating the old memalign behaviour, but I don't<br>
> > > think it would make sense.<br>
> ><br>
> > I think it makes more sense than using posix_memalign() everywhere<br>
> > and then ignoring the return variable that tells you it failed...<br>
> ><br>
> > > I searched for this, but didn't find any reasonable answer:<br>
> > > How long can be things in standard libraries marked obsolete before<br>
> > > removing?<br>
> ><br>
> > With a wrapper, we don't care.<br>
> ><br>
> > > [1] man memalign:<br>
> > > On many systems there are alignment restrictions, for example, on<br>
> > buf-<br>
> > > fers used for direct block device I/O. POSIX specifies the<br>
> > path-<br>
> > > conf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is<br>
> > needed.<br>
> > > Now one can use posix_memalign() to satisfy this requirement.<br>
> > ><br>
> > > posix_memalign() verifies that alignment matches the<br>
> > requirements<br>
> > > detailed above. memalign() may not check that the alignment<br>
> > argument<br>
> > > is correct.<br>
> ><br>
> > Yes, you can get it wrong with memalign. But we don't, because we<br>
> > follow the rules for DIO buffer alignment and set it correctly.<br>
> > Being able to directly control the alignment of the memory buffer is<br>
> > a reason for using memalign() over posix_memalign(), not the other<br>
> > way around.<br>
> ><br>
><br>
> So a wrapper used on all platforms is an acceptable solution? All right,<br>
> this explanation makes sense. I will change it that way. The only question<br>
> I have now is whether to use posix_memalign on every platform, or whether to<br>
> make it platform_memalign and use the old memalign inside for Linux.<br>
<br>
</div></div>No need for a wrapper on platforms that support memalign. We can add<br>
a wrapper when and if memalign ever goes away (which, FWIW, will<br>
break lots of code). Indeed, we alreadyhave these platform dependent<br>
"wrappers":<br>
<br>
include/darwin.h:#define memalign(a,sz) valloc(sz)<br>
include/freebsd.h:#define memalign(a,sz) valloc(sz)<br>
<br>
The question now is - do we even need to change anything?<br>
<br>
<a href="https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html" rel="noreferrer" target="_blank">https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/valloc.3.html</a><br>
<br>
"The valloc() function allocates size bytes of memory and returns a<br>
pointer to the allocated memory. The allocated memory is<br>
aligned on a page boundary"<br>
<br>
Which means it does pretty exactly the same thing as<br>
posix_memalign(), and so we don't need to change anything, right?<br>
<div><div><br></div></div></blockquote><div><br></div><div>Mmm, I'm sure I had some issue with valloc - that was why I decided to replace it.</div><div>But now, I can't remember what exactly it was and everything seems to work the same</div><div>with or without it. :-/</div><div>So maybe the real cause of the issue was something else, fixed in another patch,</div><div>making this one abundant...</div><div><br></div><div>OK, I'm moving it out of the patchset. And I'm thinking about some private issue</div><div>tracker where I can make notes, reference commits and such. :D</div></div><br clear="all"><div>Cheers,</div><div>Jan</div><div><br></div>-- <br><div><div dir="ltr"><div>Jan Tulak<br></div><a href="mailto:jtulak@redhat.com" target="_blank">jtulak@redhat.com</a><br></div></div>
</div></div>