Thread (18 messages) 18 messages, 7 authors, 2016-08-05

[RFC 3/3] kexec: extend kexec_file_load system call

From: mark.rutland@arm.com (Mark Rutland)
Date: 2016-07-19 10:52:09
Also in: kexec, linuxppc-dev, lkml

On Tue, Jul 19, 2016 at 08:55:56AM +0800, Dave Young wrote:
On 07/18/16 at 11:07am, Mark Rutland wrote:
quoted
On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote:
quoted
I do not think it is worth to add another syscall for extra fds.
We have open(2) as an example for different numbers of arguments
already.
Did we change the syscall interface for that?

I was under the impression that there was always one underlying syscall,
and the C library did the right thing to pass the expected information
to the underlying syscall.
I'm not sure kexec_load and kexec_file_load were included in glibc, we use
syscall directly in kexec-tools.

kexec_load man pages says there are no wrappers for both kexec_load and
kexec_file_load in glibc.
For the above, I was talking about how open() was handled.

If there are no userspace wrappers, then the two cases aren't comparable
in the first place...
quoted
That's rather different to changing the underlying syscall.

Regardless of how this is wrapped in userspace, I do not think modifying
the existing prototype is a good idea, and I think this kind of
extension needs to be a new syscall.
Hmm, as I replied to Vivek, there is one case about the flags, previously
the new flag will be regarded as invalid, but not we extend it it will be
valid, this maybe the only potential bad case.
It's true that adding suport for new flags will change the behaviour of
what used to be error cases. We generally expect real users to not be
making pointless calls for which they rely on an error being returned in
all cases.

Regardless, this extended syscall changes some underlying assumptions
made with the development of kexec_file_load, and I think treating this
as an extension is not a great idea. From a user's perspective there is
little difference between passing an additional flag or using a
different syscall number, so I don't think that we gain much by altering
the existing prototype relative to allocating a new syscall number.

Thus, I think that if this is necessary it should be treated as a new
syscall.

Thanks,
Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help