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

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

On 11/21/2014 01:26 PM, David Herrmann wrote:
> Hi
> 
> 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?"
> 
> Sure, will add that in v2.

Awesome. Thanks.

>> 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
> 
> I already wrote extensive tests which are included in the kernel. I
> will try to extract a sensible part and put it into glibc.

Thanks again. Part of the purpose of the glibc tests is to make sure
the wrapper is working, and the kernel meets glibc's expectations.
The tests need not be as thorough as the kernel tests, but should
exercise the ways in which a user might call the function. Generally
I would like to see it's common use, common failures, and that's it.

>> - 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.
> 
> My kernel patches already had man-pages included. I'm currently
> talking with Michael Kerrisk to get them upstream. I will try to
> include something for llio.texi in v2.

Thank you. Anything would be better than nothing.
 
>> Lastly you'll want to review:
>> https://sourceware.org/glibc/wiki/Contribution%20checklist
>>
>> The present patch is mechanical in nature and doesn't require copyright
>> assignment, but adding the test case, and manual entry brings you into
>> legally significant territory. Do you have a copyright assignment with
>> the FSF for glibc?
> 
> I remember someone telling me RedHat had a copyright agreement with
> the FSF, but the link explicitly states you need it from the _author_.
> I will send v2 as 2 patches, if you consider either a non-mechanical
> contribution, we will have to delay it until my copyright agreement
> with the FSF is done.

If you work for Red Hat, then Red Hat's copyright assignment covers you.

If you don't work for Red Hat then you need to have a copyright assignment
signed by your employer, and I can help with that. Once that's signed
you can contribute all you want to glibc (following the rules for the
type of assignment you signed).

If you are an individual then you can sign an individual copyright
assignment, if your work can't claim copyright on your work e.g. did
it with your own laptop, on your own time, and distinctly different
from your day job.

If you have any questions here, please don't hesitate to ask.

Cheers,
Carlos.