[PATCH 2/2] asm-generic: add memfd_create system call to unistd.h

[vgoyal@redhat.com (Vivek Goyal)]

On Mon, Aug 18, 2014 at 06:40:10PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 18, 2014 at 01:15:40PM -0400, Vivek Goyal wrote:
> > On Fri, Aug 15, 2014 at 02:55:20PM +0100, Will Deacon wrote:
> > > What I meant was, if I wire it into asm-generic/unistd.h then it will return
> > > -ENOEXEC for architectures using that file (e.g. arm64).
> > > 
> > > Patch below, but I don't think it's very useful.
> > > 
> > 
> > Hi Will,
> > 
> > I have not even defined a syscall number for other arches. IIUC, this
> > patch will forcibly introduce a syscall number for the new syscall for
> > arches which use asm-generic/unistd.h.
> > 
> > So question I have is that why should we do it now. One can do it once
> > somebody enables kexec_file_load() on arm64.
> > 
> > Right now I see that kexec_file_load() gets compiled if CONFIG_KEXEC=y. So
> > even on arm64 it must be getting compiled in. But it is not being hooked
> > up using system call table. So there should not be any way to invoke
> > syscalll definition. So my understand is that in current form, one can
> > not invoke kexec_file_load() on arm64. Is that right.
> > 
> > Now I have put one more patch to make compilation of kexec_file_load()
> > conditional on config option CONFIG_KEXEC_FILE. And this option can
> > be enabled only on x86_64. That means kexec_file_load() will not even
> > be compiled in on arm64 (once the patch gets merged). Right now patch
> > is sitting in andrew's tree.
> > 
> > http://ozlabs.org/~akpm/mmotm/broken-out/kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch
> > 
> > Can you please help me understand that why do we need this patch if at
> > this point of time we are not even fixing a system call number for
> > kexec_file_load() for arches except x86_64.
> 
> >From what I read, the only arch which supports this call is x86_64, and
> it requires arch code make work.  So simply wiring up the syscall is not
> enough.
> 

Yes, it will require some arch work (more arch specific kernel image
format related work) to make syscall work on other arches. Generic
portion of the syscall should work without any significant change.

> What is probably worth doing is reserving the syscall number _if_ it's
> going to be useful on architectures - by that, I mean inserting the
> syscall number with a comment in the unistd.h file, rather than
> defining a constant.

I think this syscall is going to be useful on other arches also. I
think specially on arm64 where UEFI is there and I am hoping at
some point of time secureboot on arm64 machines will show up (if it
is not already there).

Do we have to reserve a syscall number now. Does it break anything. Or
it can be reserved later once somebody decides to enable this syscall
on arm64 or any other arch which uses generic/unistd.h.

Right now it sounds more like nice to have item.

Thanks
Vivek