Re: [PATCH 1/5] kexec: Fix make headers_check

From: Paul Bolle
Date: Sat Aug 30 2014 - 08:52:35 EST


[Added Peter Anvin.]

On Mon, 2014-08-25 at 13:22 -0400, Vivek Goyal wrote:
> On Fri, Aug 22, 2014 at 06:39:47PM +0000, Geoff Levand wrote:
> > Remove the unneded declaration for a kexec_load() routine.
> >
> > Fixes errors like these when running 'make headers_check':
> >
> > include/uapi/linux/kexec.h: userspace cannot reference function or variable defined in the kernel
> >
> > Signed-off-by: Geoff Levand <geoff@xxxxxxxxxxxxx>
>
> I think Paul Bolle tried to remove this in the past and maximilian
> had objections.
>
> http://lists.infradead.org/pipermail/kexec/2014-January/010902.html

I've wanted to resend my patch, perhaps with a new commit explanation,
for quite some time now. I never got around doing that.

> I can't see that how exporting kernel prototype helps here.

It doesn't, for the reasons I've set out in
http://lists.infradead.org/pipermail/kexec/2014-January/010900.html . In
short: why bother using this prototype if one still needs to define the
matching function oneself?

> kexec-tools
> seems to be using syscall(__NR_kexec_load) directly for non-xen case. So
> I would be fine with removing this definition. Just trying to make sure
> that it does not break any other library or users of this declaration.

Obviously, this can only break compiling those libraries, or other
users. It can't break already compiled binaries. Besides I don't think
those libraries, etc actually exist. Maximilian mentioned klibc in
January, but I wasn't able to find a version of klibc that cared about
this prototype. No one pointed me at a version that does (or any other
library, etc., for that matter).

(If we do decide to keep this prototype, we should special case this
prototype in headers_check.pl just to silence the build.)

The above can be summarized like this:
Acked-by: Paul Bolle <pebolle@xxxxxxxxxx>


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/