This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH RFC] Add support for linux memfd_create syscall


Morning Carlos,

On 9 January 2015 at 15:40, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/09/2015 09:15 AM, Michael Kerrisk wrote:
>> Hi David and Carlos,
>>
>> @David: what's the state of the with respect to revising your patches for glibc?
>>
>> On Fri, Nov 21, 2014 at 7:12 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 10/17/2014 05:21 AM, David Herrmann wrote:
>>>> The memfd_create() syscall was released with linux-3.17. It's a linux-only
>>>> syscall and returns a shmem file-descriptor backed by anonymous memory
>>>> in a kernel-internal shmem mount.
>>>
>>> In general I'm trying hard to make this kind of patch easy to accept.
>>>
>>> See the WIP consensus here:
>>> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
>>>
>>> In order to get your patch accepted you have answer some implicit
>>> questions like "How do users use it?" "Why do users need it?"
>>>
>>> From a high-level perspective your patch is missing:
>>>
>>> - A test case if possible with non-root privs, or an xcheck test if root
>>>   is required.
>>>   e.g. ./sysdeps/unix/sysv/linux/tst-memfd_create.c
>>>
>>> - Documentation for the manual covering the use of the function.
>>>   e.g. ./manual/llio.texi, new section under low-level IO, and specify
>>>   that it is Linux specific. Feel free to submit your own text to the
>>>   linux-kernel man pages to get a new man page created.
>>
>> @ Carlos: it *sounds* like you're saying that it's glibc policy that
>> an API must have tests and glibc manual documentation in order to get
>> admitted into the library. Is that really what you mean?
>
> There is no policy, and nothing is set in stone. However, *I* want
> a test written for this, and as a submitter you're looking for reviewer
> consensus. Would anybody really argue that we don't need tests in this
> day and age?

I certainly would not.

But, my question was a little tendentious. It seems the bar has been
rather lower for native glibc APIs in the past, with many of them not
getting documented. So one reading of your comment could have been:
we're imposing a higher bar on outsiders (i.e., APIs imported from the
Linux kernel). I don't imagine that's what you really mean, but when I
first read your comments I did a double take along those lines.

> See step 6 in the contribution checklist:
>
> "6. Testing"
> "* Adding a test-case to the test suite may increase the likelihood
>    of acceptance of your patch. In some cases it may be necessary. "
> https://sourceware.org/glibc/wiki/Contribution%20checklist#Testing
>
> In this case I would really like to see a test case. It should not be
> too hard to write and I can help with the glibc esoterica if required.

Sounds good.

>> FWIW, I've recently been doing heavy editing of David's man pages
>> patches. They're now in a much better shape for release, but there's
>> still a number of points I want to resolve before releasing them. In
>> the meantime, they are sitting in a branch at
>> http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_memfd_create
>> and I have just sent out a mail (linux-man@vger.kernel.org, lkml)
>> requesting some review of the pages.
>
> I'm not going to look at those in the event that I want to help
> draft the GFDL version of the glibc manual for the function.
> Though I'd hope David and you contribute your text to glibc for
> inclusion in some form in the manual.

I could do that, but is it possible to do this without a CLA (e.g.,
placing into public domain, or disclaiming copyright, or some such)?
Thing is, I'm not a fan of CLAs.

> My apologies if any of this sounds cranky, I left my morning
> coffee downstairs :-)

It's okay -- I hope you got your coffee by now ;-).

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]