Since v3.5 kexec.h is exported to userspace. That includes its
declaration of kexec_load():
extern int kexec_load(void *, size_t, struct kexec_segment *,
unsigned long int);
This declaration isn't very useful to userspace programs on itself. They
still have to define a matching function (which basically wraps the
kexec_load syscall). I'm not aware of programs or libraries that actually
do that.
It can be removed. The programs that actually use it, if there
are any, should then provide their own declaration to keep compiling.
Already compiled binaries will not be affected.
This gets rid of the headers_check warning that can be seen ever since
this header was exported:
[...]/usr/include/linux/kexec.h:49: userspace cannot reference function or variable defined in the kernel
Signed-off-by: Paul Bolle <[email protected]>
---
This declaration of kexec_load() was added to kexec.h in commit
29a5c67e7a ("kexec: export kexec.h to user space").
include/uapi/linux/kexec.h | 7 -------
1 file changed, 7 deletions(-)
diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index 104838f..c7897b6 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -42,13 +42,6 @@ struct kexec_segment {
const void *mem;
size_t memsz;
};
-
-/* Load a new kernel image as described by the kexec_segment array
- * consisting of passed number of segments at the entry-point address.
- * The flags allow different useage types.
- */
-extern int kexec_load(void *, size_t, struct kexec_segment *,
- unsigned long int);
#endif /* __KERNEL__ */
#endif /* _UAPILINUX_KEXEC_H */
--
1.8.4.2
On Wed, Jan 15, 2014 at 02:17:04PM +0100, Paul Bolle wrote:
> Since v3.5 kexec.h is exported to userspace. That includes its
> declaration of kexec_load():
> extern int kexec_load(void *, size_t, struct kexec_segment *,
> unsigned long int);
>
> This declaration isn't very useful to userspace programs on itself. They
> still have to define a matching function (which basically wraps the
> kexec_load syscall). I'm not aware of programs or libraries that actually
> do that.
>
> It can be removed. The programs that actually use it, if there
> are any, should then provide their own declaration to keep compiling.
> Already compiled binaries will not be affected.
nack, klibc uses the header and there was some discussion that glibc
could/should use it too. I didn't follow kexec git, but there is/was
a version that just uses the kexec_load() if the c library provides it.
Until Santa Claus materialises in form of a direct kernel user-space API,
see follow ups on http://lwn.net/Articles/534682/ and proposal by hpa
> This gets rid of the headers_check warning that can be seen ever since
> this header was exported:
> [...]/usr/include/linux/kexec.h:49: userspace cannot reference function or variable defined in the kernel
>
this is the wrong way of fix.
--
maks
On Wed, 2014-01-15 at 14:38 +0100, Maximilian Attems wrote:
> On Wed, Jan 15, 2014 at 02:17:04PM +0100, Paul Bolle wrote:
> > Since v3.5 kexec.h is exported to userspace. That includes its
> > declaration of kexec_load():
> > extern int kexec_load(void *, size_t, struct kexec_segment *,
> > unsigned long int);
> >
> > This declaration isn't very useful to userspace programs on itself. They
> > still have to define a matching function (which basically wraps the
> > kexec_load syscall). I'm not aware of programs or libraries that actually
> > do that.
> >
> > It can be removed. The programs that actually use it, if there
> > are any, should then provide their own declaration to keep compiling.
> > Already compiled binaries will not be affected.
>
> nack, klibc uses the header and there was some discussion that glibc
> could/should use it too.
The versions of klibc I stumbled on (via codesearch.debian.net) didn't
use a kexec_load() that match that declaration. Has that changed? In
which version?
> I didn't follow kexec git, but there is/was
> a version that just uses the kexec_load() if the c library provides it.
> Until Santa Claus materialises in form of a direct kernel user-space API,
> see follow ups on http://lwn.net/Articles/534682/ and proposal by hpa
>
> > This gets rid of the headers_check warning that can be seen ever since
> > this header was exported:
> > [...]/usr/include/linux/kexec.h:49: userspace cannot reference function or variable defined in the kernel
> >
>
> this is the wrong way of fix.
Paul Bolle
We shouldn't put prototypes of user-space functions in the kernel, at least not until we actually export all the signatures. The prototype should instead be in a userspace <sys/kexec.h> header.
Maximilian Attems <[email protected]> wrote:
>
>On Wed, Jan 15, 2014 at 02:17:04PM +0100, Paul Bolle wrote:
>> Since v3.5 kexec.h is exported to userspace. That includes its
>> declaration of kexec_load():
>> extern int kexec_load(void *, size_t, struct kexec_segment *,
>> unsigned long int);
>>
>> This declaration isn't very useful to userspace programs on itself.
>They
>> still have to define a matching function (which basically wraps the
>> kexec_load syscall). I'm not aware of programs or libraries that
>actually
>> do that.
>>
>> It can be removed. The programs that actually use it, if there
>> are any, should then provide their own declaration to keep compiling.
>> Already compiled binaries will not be affected.
>
>nack, klibc uses the header and there was some discussion that glibc
>could/should use it too. I didn't follow kexec git, but there is/was
>a version that just uses the kexec_load() if the c library provides it.
>Until Santa Claus materialises in form of a direct kernel user-space
>API,
>see follow ups on http://lwn.net/Articles/534682/ and proposal by hpa
>
>> This gets rid of the headers_check warning that can be seen ever
>since
>> this header was exported:
>> [...]/usr/include/linux/kexec.h:49: userspace cannot reference
>function or variable defined in the kernel
>>
>
>this is the wrong way of fix.
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.