Re: [PATCH 08/15] kexec: New syscall kexec_file_load() declaration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 26, 2014 at 02:03:17PM -0700, Andy Lutomirski wrote:
> On Thu, Jun 26, 2014 at 1:43 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> > On Thu, Jun 26, 2014 at 04:33:37PM -0400, Vivek Goyal wrote:
> >> This is the new syscall kexec_file_load() declaration/interface. I have
> >> reserved the syscall number only for x86_64 so far. Other architectures
> >> (including i386) can reserve syscall number when they enable the support
> >> for this new syscall.
> >>
> >> Signed-off-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
> >> CC: linux-api@xxxxxxxxxxxxxxx
> >
> > +.BR KEXEC_FILE_NO_INITRAMFS
> > +Loading initrd/initramfs is optional. Specify this flag if no initramfs
> > +is being loaded. If this flag is set, kernel will ignore the value passed
> > +in
> 
> This seems pointless.  Why not just pass -1 for initrd_fd to indicate
> that no initrd is needed?

I was not sure whether negative fd should be treated as error and system
call should fail or it should be treated as user does not want to load
initrd and system call succeeds.

I was concerned about the cases where application does an fd = open(),
operation fails and fd contains -1. Caller does not check fd and
passed it to kexec system call.

I thought that in such cases we should error out saying initrd fd is
not valid. Instead of continuing and loading kernel without initrd. A
user might be surprised.

This is little defensive programming. But I am open to change it if
the perception is that above is not a valid concern.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux