[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140605152209.GC14083@redhat.com>
Date: Thu, 5 Jun 2014 11:22:09 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: WANG Chao <chaowang@...hat.com>
Cc: linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
ebiederm@...ssion.com, hpa@...or.com, mjg59@...f.ucam.org,
greg@...ah.com, bp@...en8.de, jkosina@...e.cz, dyoung@...hat.com,
bhe@...hat.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 06/13] kexec: New syscall kexec_file_load() declaration
On Thu, Jun 05, 2014 at 11:16:39AM -0400, Vivek Goyal wrote:
> On Thu, Jun 05, 2014 at 05:56:03PM +0800, WANG Chao wrote:
>
> [..]
> > > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > > index c435c5f..a3044e6 100644
> > > --- a/kernel/kexec.c
> > > +++ b/kernel/kexec.c
> > > @@ -1098,6 +1098,13 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t, entry,
> > > }
> > > #endif
> > >
> > > +SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > > + const char __user *, cmdline_ptr, unsigned long,
> > > + cmdline_len, unsigned long, flags)
> >
> > initrd is optional for system boot.
> >
> > How about using int *kernel_fd and int *initrd_fd as the argument? Then
> > if I don't need initrd, in userspace I can do this:
>
> Hi Chao,
>
> I really am not too keen converting plain int fd arguments into pointers.
>
> Given the fact that fd is int, that means all valid values are greater
> than 0. How about using -1 to denote that initrd is not being loaded?
>
> This does create one little anomaly and that is for all -ve values we
> will return -EBADF except -1 which we special cased.
Or we could do.
- Define extra flag which should be set by user if valid initrd fd is not
being passed. Say, KEXEC_FILE_NO_INITRAMFS. And if kernel sees that flag
it will not try to parse value passed in argument initrd_fd at all.
I think I like this better.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists