[PATCH] kexec_load manpage

[PATCH] kexec_load manpage

[Andi Kleen]

Here are the beginnings of a kexec_load manpage.

Probably needs some more review from Eric and may need some additional
information.

The syscall is actually only usable with a kernel patch to export
the header I just sent separately.

Also added the kexec subcall to reboot(2)

-Andi

diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
new file mode 100644
index 0000000..f486641
--- /dev/null
+++ b/man2/kexec_load.2
@@ -0,0 +1,94 @@
+.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
+.SH NAME
+kexec_load \- Load a new kernel for later execution.
+.SH SYNOPSIS
+.b #include <linux/kexec.h>
+.br
+.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
+.br
+.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
+.SH DESCRIPTION
+.BR kexec_load 
+loads a new kernel that can be executed later
+by 
+.I reboot(2).
+An alternative approach is to specify
+.B KEXEC_ON_CRASH
+in the 
+.I flags
+argument and then the new kernel will be automatically executed on a 
+system crash. 
+.\" XXX figure out how this is really used 
+With 
+.B KEXEC_PRESERVE_CONTEXT 
+specified in 
+.I flags
+kexec will preserve the system hard and 
+software state before executing the kexec kernel. This 
+could be used for system suspend.
+
+.I flags
+also contains the architecture of the executed kernel or
+be 
+.I KEXEC_ARCH_DEFAULT
+for the current architecture.
+Valid architectures are 
+.I KEXEC_ARCH_I386,
+.I KEXEC_ARCH_X86_64,
+.I KEXEC_ARCH_PPC,
+.I KEXEC_ARCH_PPC64,
+.I KEXEC_ARCH_IA_64,
+.I KEXEC_ARCH_ARM,
+.I KEXEC_ARCH_S390,
+.I KEXEC_ARCH_SH,
+.I KEXEC_ARCH_MIPS,
+.I KEXEC_ARCH_MIPS_LE.
+The architecture must be executable on the CPU of the system.
+
+.I entry 
+is the virtual entry address in the kernel image.
+.I nr_segments
+is the number of segments pointed to by the 
+.I segments
+pointer. 
+.I segments 
+is an array of 
+.I struct kexec_segment
+structures which define the kernel layout:
+.in +4n
+.nf
+
+struct kexec_segment {
+	void   *buf;	/* Buffer in user space */
+	size_t  bufsz;	/* Buffer length in user space */
+	void   *mem;	/* Virtual address of kernel */
+	size_t  memsz;	/* Virtual address length */
+};
+.fi
+.in
+.PP
+.\" XXX elaborate on this
+The kernel image defined by
+.I segments
+is copied from the calling process into previously reserved memory.
+.SH CONFORMING TO
+This system call is Linux-specific.
+.SH NOTES
+kexec_load is currently not defined in glibc. To call it use:
+.in +4n
+.nf
+#define _GNU_SOURCE
+#include <syscall.h>
+#include <asm/unistd.h>
+#include <linux/kexec.h>
+
+ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
+.fi
+.in
+.PP
+.I linux/kexec.h as a exported header is only available in 2.6.38
+and later kernels, in earlier kernels the constants need to be copied
+out of the kernel source.
+.SH SEE ALSO
+.BR syscall (2),
+.BR reboot (2)
diff --git a/man2/reboot.2 b/man2/reboot.2
index 253bd34..87204b1 100644
--- a/man2/reboot.2
+++ b/man2/reboot.2
@@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
 anything at present (2.1.122), but the type of reboot can be
 determined by kernel command-line arguments ("reboot=...") to be
 either warm or cold, and either hard or through the BIOS.
+.TP
+.B LINUX_REBOOT_KEXEC
+executes a kernel that has been loaded earlier
+with 
+.I kexec_load(2).
 .SH "RETURN VALUE"
 For the values of
 .I cmd
@@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
 .BR capabilities (7),
 .BR ctrlaltdel (8),
 .BR halt (8),
-.BR reboot (8)
+.BR reboot (8),
+.BR kexec_load (2)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Eric W. Biederman]

Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:

> Here are the beginnings of a kexec_load manpage.
>
> Probably needs some more review from Eric and may need some additional
> information.
>
> The syscall is actually only usable with a kernel patch to export
> the header I just sent separately.

The syscall has been used for years with a separate non-kernel header.


Eric


> Also added the kexec subcall to reboot(2)
>
> -Andi
>
> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
> new file mode 100644
> index 0000000..f486641
> --- /dev/null
> +++ b/man2/kexec_load.2
> @@ -0,0 +1,94 @@
> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +kexec_load \- Load a new kernel for later execution.
> +.SH SYNOPSIS
> +.b #include <linux/kexec.h>
> +.br
> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
> +.br
> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
> +.SH DESCRIPTION
> +.BR kexec_load 
> +loads a new kernel that can be executed later
> +by 
> +.I reboot(2).
> +An alternative approach is to specify
> +.B KEXEC_ON_CRASH
> +in the 
> +.I flags
> +argument and then the new kernel will be automatically executed on a 
> +system crash. 
> +.\" XXX figure out how this is really used 
> +With 
> +.B KEXEC_PRESERVE_CONTEXT 
> +specified in 
> +.I flags
> +kexec will preserve the system hard and 
> +software state before executing the kexec kernel. This 
> +could be used for system suspend.
> +
> +.I flags
> +also contains the architecture of the executed kernel or
> +be 
> +.I KEXEC_ARCH_DEFAULT
> +for the current architecture.
> +Valid architectures are 
> +.I KEXEC_ARCH_I386,
> +.I KEXEC_ARCH_X86_64,
> +.I KEXEC_ARCH_PPC,
> +.I KEXEC_ARCH_PPC64,
> +.I KEXEC_ARCH_IA_64,
> +.I KEXEC_ARCH_ARM,
> +.I KEXEC_ARCH_S390,
> +.I KEXEC_ARCH_SH,
> +.I KEXEC_ARCH_MIPS,
> +.I KEXEC_ARCH_MIPS_LE.
> +The architecture must be executable on the CPU of the system.
> +
> +.I entry 
> +is the virtual entry address in the kernel image.

Physical.

> +.I nr_segments
> +is the number of segments pointed to by the 
> +.I segments
> +pointer. 
> +.I segments 
> +is an array of 
> +.I struct kexec_segment
> +structures which define the kernel layout:
> +.in +4n
> +.nf
> +
> +struct kexec_segment {
> +	void   *buf;	/* Buffer in user space */
> +	size_t  bufsz;	/* Buffer length in user space */
> +	void   *mem;	/* Virtual address of kernel */
> +	size_t  memsz;	/* Virtual address length */

There are again physical addresses.

There is an expectation that at hand off from sys_kexec that
virtual and physical addresses will be identity mapped.  But
this isn't the old Alpha booting convention where you have
a virtual address and then you have to parse the page table
to figure out where your kernel was actually loaded.

> +};
> +.fi
> +.in
> +.PP
> +.\" XXX elaborate on this
> +The kernel image defined by
> +.I segments
> +is copied from the calling process into previously reserved memory.
> +.SH CONFORMING TO
> +This system call is Linux-specific.
> +.SH NOTES
> +kexec_load is currently not defined in glibc. To call it use:
> +.in +4n
> +.nf
> +#define _GNU_SOURCE
> +#include <syscall.h>
> +#include <asm/unistd.h>
> +#include <linux/kexec.h>
> +
> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
> +.fi
> +.in
> +.PP
> +.I linux/kexec.h as a exported header is only available in 2.6.38
> +and later kernels, in earlier kernels the constants need to be copied
> +out of the kernel source.
> +.SH SEE ALSO
> +.BR syscall (2),
> +.BR reboot (2)
> diff --git a/man2/reboot.2 b/man2/reboot.2
> index 253bd34..87204b1 100644
> --- a/man2/reboot.2
> +++ b/man2/reboot.2
> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>  anything at present (2.1.122), but the type of reboot can be
>  determined by kernel command-line arguments ("reboot=...") to be
>  either warm or cold, and either hard or through the BIOS.
> +.TP
> +.B LINUX_REBOOT_KEXEC
> +executes a kernel that has been loaded earlier
> +with 
> +.I kexec_load(2).
>  .SH "RETURN VALUE"
>  For the values of
>  .I cmd
> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>  .BR capabilities (7),
>  .BR ctrlaltdel (8),
>  .BR halt (8),
> -.BR reboot (8)
> +.BR reboot (8),
> +.BR kexec_load (2)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Eric W. Biederman]

Andi Kleen <andi@firstfloor.org> writes:

> Here are the beginnings of a kexec_load manpage.
>
> Probably needs some more review from Eric and may need some additional
> information.
>
> The syscall is actually only usable with a kernel patch to export
> the header I just sent separately.

The syscall has been used for years with a separate non-kernel header.


Eric


> Also added the kexec subcall to reboot(2)
>
> -Andi
>
> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
> new file mode 100644
> index 0000000..f486641
> --- /dev/null
> +++ b/man2/kexec_load.2
> @@ -0,0 +1,94 @@
> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +kexec_load \- Load a new kernel for later execution.
> +.SH SYNOPSIS
> +.b #include <linux/kexec.h>
> +.br
> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
> +.br
> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
> +.SH DESCRIPTION
> +.BR kexec_load 
> +loads a new kernel that can be executed later
> +by 
> +.I reboot(2).
> +An alternative approach is to specify
> +.B KEXEC_ON_CRASH
> +in the 
> +.I flags
> +argument and then the new kernel will be automatically executed on a 
> +system crash. 
> +.\" XXX figure out how this is really used 
> +With 
> +.B KEXEC_PRESERVE_CONTEXT 
> +specified in 
> +.I flags
> +kexec will preserve the system hard and 
> +software state before executing the kexec kernel. This 
> +could be used for system suspend.
> +
> +.I flags
> +also contains the architecture of the executed kernel or
> +be 
> +.I KEXEC_ARCH_DEFAULT
> +for the current architecture.
> +Valid architectures are 
> +.I KEXEC_ARCH_I386,
> +.I KEXEC_ARCH_X86_64,
> +.I KEXEC_ARCH_PPC,
> +.I KEXEC_ARCH_PPC64,
> +.I KEXEC_ARCH_IA_64,
> +.I KEXEC_ARCH_ARM,
> +.I KEXEC_ARCH_S390,
> +.I KEXEC_ARCH_SH,
> +.I KEXEC_ARCH_MIPS,
> +.I KEXEC_ARCH_MIPS_LE.
> +The architecture must be executable on the CPU of the system.
> +
> +.I entry 
> +is the virtual entry address in the kernel image.

Physical.

> +.I nr_segments
> +is the number of segments pointed to by the 
> +.I segments
> +pointer. 
> +.I segments 
> +is an array of 
> +.I struct kexec_segment
> +structures which define the kernel layout:
> +.in +4n
> +.nf
> +
> +struct kexec_segment {
> +	void   *buf;	/* Buffer in user space */
> +	size_t  bufsz;	/* Buffer length in user space */
> +	void   *mem;	/* Virtual address of kernel */
> +	size_t  memsz;	/* Virtual address length */

There are again physical addresses.

There is an expectation that at hand off from sys_kexec that
virtual and physical addresses will be identity mapped.  But
this isn't the old Alpha booting convention where you have
a virtual address and then you have to parse the page table
to figure out where your kernel was actually loaded.

> +};
> +.fi
> +.in
> +.PP
> +.\" XXX elaborate on this
> +The kernel image defined by
> +.I segments
> +is copied from the calling process into previously reserved memory.
> +.SH CONFORMING TO
> +This system call is Linux-specific.
> +.SH NOTES
> +kexec_load is currently not defined in glibc. To call it use:
> +.in +4n
> +.nf
> +#define _GNU_SOURCE
> +#include <syscall.h>
> +#include <asm/unistd.h>
> +#include <linux/kexec.h>
> +
> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
> +.fi
> +.in
> +.PP
> +.I linux/kexec.h as a exported header is only available in 2.6.38
> +and later kernels, in earlier kernels the constants need to be copied
> +out of the kernel source.
> +.SH SEE ALSO
> +.BR syscall (2),
> +.BR reboot (2)
> diff --git a/man2/reboot.2 b/man2/reboot.2
> index 253bd34..87204b1 100644
> --- a/man2/reboot.2
> +++ b/man2/reboot.2
> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>  anything at present (2.1.122), but the type of reboot can be
>  determined by kernel command-line arguments ("reboot=...") to be
>  either warm or cold, and either hard or through the BIOS.
> +.TP
> +.B LINUX_REBOOT_KEXEC
> +executes a kernel that has been loaded earlier
> +with 
> +.I kexec_load(2).
>  .SH "RETURN VALUE"
>  For the values of
>  .I cmd
> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>  .BR capabilities (7),
>  .BR ctrlaltdel (8),
>  .BR halt (8),
> -.BR reboot (8)
> +.BR reboot (8),
> +.BR kexec_load (2)

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
> 
> > Here are the beginnings of a kexec_load manpage.
> >
> > Probably needs some more review from Eric and may need some additional
> > information.
> >
> > The syscall is actually only usable with a kernel patch to export
> > the header I just sent separately.
> 
> The syscall has been used for years with a separate non-kernel header.

Yes but that's not a sane interface that can be documented.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
> Andi Kleen <andi@firstfloor.org> writes:
> 
> > Here are the beginnings of a kexec_load manpage.
> >
> > Probably needs some more review from Eric and may need some additional
> > information.
> >
> > The syscall is actually only usable with a kernel patch to export
> > the header I just sent separately.
> 
> The syscall has been used for years with a separate non-kernel header.

Yes but that's not a sane interface that can be documented.

-Andi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hi Andi,

Are Eric's suggestions of "physical" below correct? If so, could you
amend the page and resubmit?

Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
separate patches, so could you split them on the resend please?

Thanks,

Michael

On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>
>> Here are the beginnings of a kexec_load manpage.
>>
>> Probably needs some more review from Eric and may need some additional
>> information.
>>
>> The syscall is actually only usable with a kernel patch to export
>> the header I just sent separately.
>
> The syscall has been used for years with a separate non-kernel header.
>
>
> Eric
>
>
>> Also added the kexec subcall to reboot(2)
>>
>> -Andi
>>
>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>> new file mode 100644
>> index 0000000..f486641
>> --- /dev/null
>> +++ b/man2/kexec_load.2
>> @@ -0,0 +1,94 @@
>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +kexec_load \- Load a new kernel for later execution.
>> +.SH SYNOPSIS
>> +.b #include <linux/kexec.h>
>> +.br
>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>> +.br
>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>> +.SH DESCRIPTION
>> +.BR kexec_load
>> +loads a new kernel that can be executed later
>> +by
>> +.I reboot(2).
>> +An alternative approach is to specify
>> +.B KEXEC_ON_CRASH
>> +in the
>> +.I flags
>> +argument and then the new kernel will be automatically executed on a
>> +system crash.
>> +.\" XXX figure out how this is really used
>> +With
>> +.B KEXEC_PRESERVE_CONTEXT
>> +specified in
>> +.I flags
>> +kexec will preserve the system hard and
>> +software state before executing the kexec kernel. This
>> +could be used for system suspend.
>> +
>> +.I flags
>> +also contains the architecture of the executed kernel or
>> +be
>> +.I KEXEC_ARCH_DEFAULT
>> +for the current architecture.
>> +Valid architectures are
>> +.I KEXEC_ARCH_I386,
>> +.I KEXEC_ARCH_X86_64,
>> +.I KEXEC_ARCH_PPC,
>> +.I KEXEC_ARCH_PPC64,
>> +.I KEXEC_ARCH_IA_64,
>> +.I KEXEC_ARCH_ARM,
>> +.I KEXEC_ARCH_S390,
>> +.I KEXEC_ARCH_SH,
>> +.I KEXEC_ARCH_MIPS,
>> +.I KEXEC_ARCH_MIPS_LE.
>> +The architecture must be executable on the CPU of the system.
>> +
>> +.I entry
>> +is the virtual entry address in the kernel image.
>
> Physical.
>
>> +.I nr_segments
>> +is the number of segments pointed to by the
>> +.I segments
>> +pointer.
>> +.I segments
>> +is an array of
>> +.I struct kexec_segment
>> +structures which define the kernel layout:
>> +.in +4n
>> +.nf
>> +
>> +struct kexec_segment {
>> +     void   *buf;    /* Buffer in user space */
>> +     size_t  bufsz;  /* Buffer length in user space */
>> +     void   *mem;    /* Virtual address of kernel */
>> +     size_t  memsz;  /* Virtual address length */
>
> There are again physical addresses.
>
> There is an expectation that at hand off from sys_kexec that
> virtual and physical addresses will be identity mapped.  But
> this isn't the old Alpha booting convention where you have
> a virtual address and then you have to parse the page table
> to figure out where your kernel was actually loaded.
>
>> +};
>> +.fi
>> +.in
>> +.PP
>> +.\" XXX elaborate on this
>> +The kernel image defined by
>> +.I segments
>> +is copied from the calling process into previously reserved memory.
>> +.SH CONFORMING TO
>> +This system call is Linux-specific.
>> +.SH NOTES
>> +kexec_load is currently not defined in glibc. To call it use:
>> +.in +4n
>> +.nf
>> +#define _GNU_SOURCE
>> +#include <syscall.h>
>> +#include <asm/unistd.h>
>> +#include <linux/kexec.h>
>> +
>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>> +.fi
>> +.in
>> +.PP
>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>> +and later kernels, in earlier kernels the constants need to be copied
>> +out of the kernel source.
>> +.SH SEE ALSO
>> +.BR syscall (2),
>> +.BR reboot (2)
>> diff --git a/man2/reboot.2 b/man2/reboot.2
>> index 253bd34..87204b1 100644
>> --- a/man2/reboot.2
>> +++ b/man2/reboot.2
>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>  anything at present (2.1.122), but the type of reboot can be
>>  determined by kernel command-line arguments ("reboot=...") to be
>>  either warm or cold, and either hard or through the BIOS.
>> +.TP
>> +.B LINUX_REBOOT_KEXEC
>> +executes a kernel that has been loaded earlier
>> +with
>> +.I kexec_load(2).
>>  .SH "RETURN VALUE"
>>  For the values of
>>  .I cmd
>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>  .BR capabilities (7),
>>  .BR ctrlaltdel (8),
>>  .BR halt (8),
>> -.BR reboot (8)
>> +.BR reboot (8),
>> +.BR kexec_load (2)
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface" http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hi Andi,

Are Eric's suggestions of "physical" below correct? If so, could you
amend the page and resubmit?

Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
separate patches, so could you split them on the resend please?

Thanks,

Michael

On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andi Kleen <andi@firstfloor.org> writes:
>
>> Here are the beginnings of a kexec_load manpage.
>>
>> Probably needs some more review from Eric and may need some additional
>> information.
>>
>> The syscall is actually only usable with a kernel patch to export
>> the header I just sent separately.
>
> The syscall has been used for years with a separate non-kernel header.
>
>
> Eric
>
>
>> Also added the kexec subcall to reboot(2)
>>
>> -Andi
>>
>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>> new file mode 100644
>> index 0000000..f486641
>> --- /dev/null
>> +++ b/man2/kexec_load.2
>> @@ -0,0 +1,94 @@
>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +kexec_load \- Load a new kernel for later execution.
>> +.SH SYNOPSIS
>> +.b #include <linux/kexec.h>
>> +.br
>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>> +.br
>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>> +.SH DESCRIPTION
>> +.BR kexec_load
>> +loads a new kernel that can be executed later
>> +by
>> +.I reboot(2).
>> +An alternative approach is to specify
>> +.B KEXEC_ON_CRASH
>> +in the
>> +.I flags
>> +argument and then the new kernel will be automatically executed on a
>> +system crash.
>> +.\" XXX figure out how this is really used
>> +With
>> +.B KEXEC_PRESERVE_CONTEXT
>> +specified in
>> +.I flags
>> +kexec will preserve the system hard and
>> +software state before executing the kexec kernel. This
>> +could be used for system suspend.
>> +
>> +.I flags
>> +also contains the architecture of the executed kernel or
>> +be
>> +.I KEXEC_ARCH_DEFAULT
>> +for the current architecture.
>> +Valid architectures are
>> +.I KEXEC_ARCH_I386,
>> +.I KEXEC_ARCH_X86_64,
>> +.I KEXEC_ARCH_PPC,
>> +.I KEXEC_ARCH_PPC64,
>> +.I KEXEC_ARCH_IA_64,
>> +.I KEXEC_ARCH_ARM,
>> +.I KEXEC_ARCH_S390,
>> +.I KEXEC_ARCH_SH,
>> +.I KEXEC_ARCH_MIPS,
>> +.I KEXEC_ARCH_MIPS_LE.
>> +The architecture must be executable on the CPU of the system.
>> +
>> +.I entry
>> +is the virtual entry address in the kernel image.
>
> Physical.
>
>> +.I nr_segments
>> +is the number of segments pointed to by the
>> +.I segments
>> +pointer.
>> +.I segments
>> +is an array of
>> +.I struct kexec_segment
>> +structures which define the kernel layout:
>> +.in +4n
>> +.nf
>> +
>> +struct kexec_segment {
>> +     void   *buf;    /* Buffer in user space */
>> +     size_t  bufsz;  /* Buffer length in user space */
>> +     void   *mem;    /* Virtual address of kernel */
>> +     size_t  memsz;  /* Virtual address length */
>
> There are again physical addresses.
>
> There is an expectation that at hand off from sys_kexec that
> virtual and physical addresses will be identity mapped.  But
> this isn't the old Alpha booting convention where you have
> a virtual address and then you have to parse the page table
> to figure out where your kernel was actually loaded.
>
>> +};
>> +.fi
>> +.in
>> +.PP
>> +.\" XXX elaborate on this
>> +The kernel image defined by
>> +.I segments
>> +is copied from the calling process into previously reserved memory.
>> +.SH CONFORMING TO
>> +This system call is Linux-specific.
>> +.SH NOTES
>> +kexec_load is currently not defined in glibc. To call it use:
>> +.in +4n
>> +.nf
>> +#define _GNU_SOURCE
>> +#include <syscall.h>
>> +#include <asm/unistd.h>
>> +#include <linux/kexec.h>
>> +
>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>> +.fi
>> +.in
>> +.PP
>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>> +and later kernels, in earlier kernels the constants need to be copied
>> +out of the kernel source.
>> +.SH SEE ALSO
>> +.BR syscall (2),
>> +.BR reboot (2)
>> diff --git a/man2/reboot.2 b/man2/reboot.2
>> index 253bd34..87204b1 100644
>> --- a/man2/reboot.2
>> +++ b/man2/reboot.2
>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>  anything at present (2.1.122), but the type of reboot can be
>>  determined by kernel command-line arguments ("reboot=...") to be
>>  either warm or cold, and either hard or through the BIOS.
>> +.TP
>> +.B LINUX_REBOOT_KEXEC
>> +executes a kernel that has been loaded earlier
>> +with
>> +.I kexec_load(2).
>>  .SH "RETURN VALUE"
>>  For the values of
>>  .I cmd
>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>  .BR capabilities (7),
>>  .BR ctrlaltdel (8),
>>  .BR halt (8),
>> -.BR reboot (8)
>> +.BR reboot (8),
>> +.BR kexec_load (2)
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface" http://blog.man7.org/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hi Andi,

Ping!

Cheers,

Michael


On Sat, Jun 26, 2010 at 3:23 PM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8@public.gmane.orgm> wrote:
> Hi Andi,
>
> Are Eric's suggestions of "physical" below correct? If so, could you
> amend the page and resubmit?
>
> Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
> separate patches, so could you split them on the resend please?
>
> Thanks,
>
> Michael
>
> On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>>
>>> Here are the beginnings of a kexec_load manpage.
>>>
>>> Probably needs some more review from Eric and may need some additional
>>> information.
>>>
>>> The syscall is actually only usable with a kernel patch to export
>>> the header I just sent separately.
>>
>> The syscall has been used for years with a separate non-kernel header.
>>
>>
>> Eric
>>
>>
>>> Also added the kexec subcall to reboot(2)
>>>
>>> -Andi
>>>
>>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>>> new file mode 100644
>>> index 0000000..f486641
>>> --- /dev/null
>>> +++ b/man2/kexec_load.2
>>> @@ -0,0 +1,94 @@
>>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>>> +.SH NAME
>>> +kexec_load \- Load a new kernel for later execution.
>>> +.SH SYNOPSIS
>>> +.b #include <linux/kexec.h>
>>> +.br
>>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>>> +.br
>>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>>> +.SH DESCRIPTION
>>> +.BR kexec_load
>>> +loads a new kernel that can be executed later
>>> +by
>>> +.I reboot(2).
>>> +An alternative approach is to specify
>>> +.B KEXEC_ON_CRASH
>>> +in the
>>> +.I flags
>>> +argument and then the new kernel will be automatically executed on a
>>> +system crash.
>>> +.\" XXX figure out how this is really used
>>> +With
>>> +.B KEXEC_PRESERVE_CONTEXT
>>> +specified in
>>> +.I flags
>>> +kexec will preserve the system hard and
>>> +software state before executing the kexec kernel. This
>>> +could be used for system suspend.
>>> +
>>> +.I flags
>>> +also contains the architecture of the executed kernel or
>>> +be
>>> +.I KEXEC_ARCH_DEFAULT
>>> +for the current architecture.
>>> +Valid architectures are
>>> +.I KEXEC_ARCH_I386,
>>> +.I KEXEC_ARCH_X86_64,
>>> +.I KEXEC_ARCH_PPC,
>>> +.I KEXEC_ARCH_PPC64,
>>> +.I KEXEC_ARCH_IA_64,
>>> +.I KEXEC_ARCH_ARM,
>>> +.I KEXEC_ARCH_S390,
>>> +.I KEXEC_ARCH_SH,
>>> +.I KEXEC_ARCH_MIPS,
>>> +.I KEXEC_ARCH_MIPS_LE.
>>> +The architecture must be executable on the CPU of the system.
>>> +
>>> +.I entry
>>> +is the virtual entry address in the kernel image.
>>
>> Physical.
>>
>>> +.I nr_segments
>>> +is the number of segments pointed to by the
>>> +.I segments
>>> +pointer.
>>> +.I segments
>>> +is an array of
>>> +.I struct kexec_segment
>>> +structures which define the kernel layout:
>>> +.in +4n
>>> +.nf
>>> +
>>> +struct kexec_segment {
>>> +     void   *buf;    /* Buffer in user space */
>>> +     size_t  bufsz;  /* Buffer length in user space */
>>> +     void   *mem;    /* Virtual address of kernel */
>>> +     size_t  memsz;  /* Virtual address length */
>>
>> There are again physical addresses.
>>
>> There is an expectation that at hand off from sys_kexec that
>> virtual and physical addresses will be identity mapped.  But
>> this isn't the old Alpha booting convention where you have
>> a virtual address and then you have to parse the page table
>> to figure out where your kernel was actually loaded.
>>
>>> +};
>>> +.fi
>>> +.in
>>> +.PP
>>> +.\" XXX elaborate on this
>>> +The kernel image defined by
>>> +.I segments
>>> +is copied from the calling process into previously reserved memory.
>>> +.SH CONFORMING TO
>>> +This system call is Linux-specific.
>>> +.SH NOTES
>>> +kexec_load is currently not defined in glibc. To call it use:
>>> +.in +4n
>>> +.nf
>>> +#define _GNU_SOURCE
>>> +#include <syscall.h>
>>> +#include <asm/unistd.h>
>>> +#include <linux/kexec.h>
>>> +
>>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>>> +.fi
>>> +.in
>>> +.PP
>>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>>> +and later kernels, in earlier kernels the constants need to be copied
>>> +out of the kernel source.
>>> +.SH SEE ALSO
>>> +.BR syscall (2),
>>> +.BR reboot (2)
>>> diff --git a/man2/reboot.2 b/man2/reboot.2
>>> index 253bd34..87204b1 100644
>>> --- a/man2/reboot.2
>>> +++ b/man2/reboot.2
>>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>>  anything at present (2.1.122), but the type of reboot can be
>>>  determined by kernel command-line arguments ("reboot=...") to be
>>>  either warm or cold, and either hard or through the BIOS.
>>> +.TP
>>> +.B LINUX_REBOOT_KEXEC
>>> +executes a kernel that has been loaded earlier
>>> +with
>>> +.I kexec_load(2).
>>>  .SH "RETURN VALUE"
>>>  For the values of
>>>  .I cmd
>>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>>  .BR capabilities (7),
>>>  .BR ctrlaltdel (8),
>>>  .BR halt (8),
>>> -.BR reboot (8)
>>> +.BR reboot (8),
>>> +.BR kexec_load (2)
>>
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface" http://blog.man7.org/
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hi Andi,

Ping!

Cheers,

Michael


On Sat, Jun 26, 2010 at 3:23 PM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
> Hi Andi,
>
> Are Eric's suggestions of "physical" below correct? If so, could you
> amend the page and resubmit?
>
> Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
> separate patches, so could you split them on the resend please?
>
> Thanks,
>
> Michael
>
> On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Andi Kleen <andi@firstfloor.org> writes:
>>
>>> Here are the beginnings of a kexec_load manpage.
>>>
>>> Probably needs some more review from Eric and may need some additional
>>> information.
>>>
>>> The syscall is actually only usable with a kernel patch to export
>>> the header I just sent separately.
>>
>> The syscall has been used for years with a separate non-kernel header.
>>
>>
>> Eric
>>
>>
>>> Also added the kexec subcall to reboot(2)
>>>
>>> -Andi
>>>
>>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>>> new file mode 100644
>>> index 0000000..f486641
>>> --- /dev/null
>>> +++ b/man2/kexec_load.2
>>> @@ -0,0 +1,94 @@
>>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>>> +.SH NAME
>>> +kexec_load \- Load a new kernel for later execution.
>>> +.SH SYNOPSIS
>>> +.b #include <linux/kexec.h>
>>> +.br
>>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>>> +.br
>>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>>> +.SH DESCRIPTION
>>> +.BR kexec_load
>>> +loads a new kernel that can be executed later
>>> +by
>>> +.I reboot(2).
>>> +An alternative approach is to specify
>>> +.B KEXEC_ON_CRASH
>>> +in the
>>> +.I flags
>>> +argument and then the new kernel will be automatically executed on a
>>> +system crash.
>>> +.\" XXX figure out how this is really used
>>> +With
>>> +.B KEXEC_PRESERVE_CONTEXT
>>> +specified in
>>> +.I flags
>>> +kexec will preserve the system hard and
>>> +software state before executing the kexec kernel. This
>>> +could be used for system suspend.
>>> +
>>> +.I flags
>>> +also contains the architecture of the executed kernel or
>>> +be
>>> +.I KEXEC_ARCH_DEFAULT
>>> +for the current architecture.
>>> +Valid architectures are
>>> +.I KEXEC_ARCH_I386,
>>> +.I KEXEC_ARCH_X86_64,
>>> +.I KEXEC_ARCH_PPC,
>>> +.I KEXEC_ARCH_PPC64,
>>> +.I KEXEC_ARCH_IA_64,
>>> +.I KEXEC_ARCH_ARM,
>>> +.I KEXEC_ARCH_S390,
>>> +.I KEXEC_ARCH_SH,
>>> +.I KEXEC_ARCH_MIPS,
>>> +.I KEXEC_ARCH_MIPS_LE.
>>> +The architecture must be executable on the CPU of the system.
>>> +
>>> +.I entry
>>> +is the virtual entry address in the kernel image.
>>
>> Physical.
>>
>>> +.I nr_segments
>>> +is the number of segments pointed to by the
>>> +.I segments
>>> +pointer.
>>> +.I segments
>>> +is an array of
>>> +.I struct kexec_segment
>>> +structures which define the kernel layout:
>>> +.in +4n
>>> +.nf
>>> +
>>> +struct kexec_segment {
>>> +     void   *buf;    /* Buffer in user space */
>>> +     size_t  bufsz;  /* Buffer length in user space */
>>> +     void   *mem;    /* Virtual address of kernel */
>>> +     size_t  memsz;  /* Virtual address length */
>>
>> There are again physical addresses.
>>
>> There is an expectation that at hand off from sys_kexec that
>> virtual and physical addresses will be identity mapped.  But
>> this isn't the old Alpha booting convention where you have
>> a virtual address and then you have to parse the page table
>> to figure out where your kernel was actually loaded.
>>
>>> +};
>>> +.fi
>>> +.in
>>> +.PP
>>> +.\" XXX elaborate on this
>>> +The kernel image defined by
>>> +.I segments
>>> +is copied from the calling process into previously reserved memory.
>>> +.SH CONFORMING TO
>>> +This system call is Linux-specific.
>>> +.SH NOTES
>>> +kexec_load is currently not defined in glibc. To call it use:
>>> +.in +4n
>>> +.nf
>>> +#define _GNU_SOURCE
>>> +#include <syscall.h>
>>> +#include <asm/unistd.h>
>>> +#include <linux/kexec.h>
>>> +
>>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>>> +.fi
>>> +.in
>>> +.PP
>>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>>> +and later kernels, in earlier kernels the constants need to be copied
>>> +out of the kernel source.
>>> +.SH SEE ALSO
>>> +.BR syscall (2),
>>> +.BR reboot (2)
>>> diff --git a/man2/reboot.2 b/man2/reboot.2
>>> index 253bd34..87204b1 100644
>>> --- a/man2/reboot.2
>>> +++ b/man2/reboot.2
>>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>>  anything at present (2.1.122), but the type of reboot can be
>>>  determined by kernel command-line arguments ("reboot=...") to be
>>>  either warm or cold, and either hard or through the BIOS.
>>> +.TP
>>> +.B LINUX_REBOOT_KEXEC
>>> +executes a kernel that has been loaded earlier
>>> +with
>>> +.I kexec_load(2).
>>>  .SH "RETURN VALUE"
>>>  For the values of
>>>  .I cmd
>>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>>  .BR capabilities (7),
>>>  .BR ctrlaltdel (8),
>>>  .BR halt (8),
>>> -.BR reboot (8)
>>> +.BR reboot (8),
>>> +.BR kexec_load (2)
>>
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface" http://blog.man7.org/
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hey Andi,

I'd like to push this page out the door, but I'm blocked doing so
until I hear back from you regarding the question below (plus a new
version of the page, if needed please).

Thanks,

Michael


On Sat, Sep 11, 2010 at 6:46 AM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8@public.gmane.orgm> wrote:
> Hi Andi,
>
> Ping!
>
> Cheers,
>
> Michael
>
>
> On Sat, Jun 26, 2010 at 3:23 PM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>> Hi Andi,
>>
>> Are Eric's suggestions of "physical" below correct? If so, could you
>> amend the page and resubmit?
>>
>> Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
>> separate patches, so could you split them on the resend please?
>>
>> Thanks,
>>
>> Michael
>>
>> On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>>>
>>>> Here are the beginnings of a kexec_load manpage.
>>>>
>>>> Probably needs some more review from Eric and may need some additional
>>>> information.
>>>>
>>>> The syscall is actually only usable with a kernel patch to export
>>>> the header I just sent separately.
>>>
>>> The syscall has been used for years with a separate non-kernel header.
>>>
>>>
>>> Eric
>>>
>>>
>>>> Also added the kexec subcall to reboot(2)
>>>>
>>>> -Andi
>>>>
>>>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>>>> new file mode 100644
>>>> index 0000000..f486641
>>>> --- /dev/null
>>>> +++ b/man2/kexec_load.2
>>>> @@ -0,0 +1,94 @@
>>>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>>>> +.SH NAME
>>>> +kexec_load \- Load a new kernel for later execution.
>>>> +.SH SYNOPSIS
>>>> +.b #include <linux/kexec.h>
>>>> +.br
>>>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>>>> +.br
>>>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>>>> +.SH DESCRIPTION
>>>> +.BR kexec_load
>>>> +loads a new kernel that can be executed later
>>>> +by
>>>> +.I reboot(2).
>>>> +An alternative approach is to specify
>>>> +.B KEXEC_ON_CRASH
>>>> +in the
>>>> +.I flags
>>>> +argument and then the new kernel will be automatically executed on a
>>>> +system crash.
>>>> +.\" XXX figure out how this is really used
>>>> +With
>>>> +.B KEXEC_PRESERVE_CONTEXT
>>>> +specified in
>>>> +.I flags
>>>> +kexec will preserve the system hard and
>>>> +software state before executing the kexec kernel. This
>>>> +could be used for system suspend.
>>>> +
>>>> +.I flags
>>>> +also contains the architecture of the executed kernel or
>>>> +be
>>>> +.I KEXEC_ARCH_DEFAULT
>>>> +for the current architecture.
>>>> +Valid architectures are
>>>> +.I KEXEC_ARCH_I386,
>>>> +.I KEXEC_ARCH_X86_64,
>>>> +.I KEXEC_ARCH_PPC,
>>>> +.I KEXEC_ARCH_PPC64,
>>>> +.I KEXEC_ARCH_IA_64,
>>>> +.I KEXEC_ARCH_ARM,
>>>> +.I KEXEC_ARCH_S390,
>>>> +.I KEXEC_ARCH_SH,
>>>> +.I KEXEC_ARCH_MIPS,
>>>> +.I KEXEC_ARCH_MIPS_LE.
>>>> +The architecture must be executable on the CPU of the system.
>>>> +
>>>> +.I entry
>>>> +is the virtual entry address in the kernel image.
>>>
>>> Physical.
>>>
>>>> +.I nr_segments
>>>> +is the number of segments pointed to by the
>>>> +.I segments
>>>> +pointer.
>>>> +.I segments
>>>> +is an array of
>>>> +.I struct kexec_segment
>>>> +structures which define the kernel layout:
>>>> +.in +4n
>>>> +.nf
>>>> +
>>>> +struct kexec_segment {
>>>> +     void   *buf;    /* Buffer in user space */
>>>> +     size_t  bufsz;  /* Buffer length in user space */
>>>> +     void   *mem;    /* Virtual address of kernel */
>>>> +     size_t  memsz;  /* Virtual address length */
>>>
>>> There are again physical addresses.
>>>
>>> There is an expectation that at hand off from sys_kexec that
>>> virtual and physical addresses will be identity mapped.  But
>>> this isn't the old Alpha booting convention where you have
>>> a virtual address and then you have to parse the page table
>>> to figure out where your kernel was actually loaded.
>>>
>>>> +};
>>>> +.fi
>>>> +.in
>>>> +.PP
>>>> +.\" XXX elaborate on this
>>>> +The kernel image defined by
>>>> +.I segments
>>>> +is copied from the calling process into previously reserved memory.
>>>> +.SH CONFORMING TO
>>>> +This system call is Linux-specific.
>>>> +.SH NOTES
>>>> +kexec_load is currently not defined in glibc. To call it use:
>>>> +.in +4n
>>>> +.nf
>>>> +#define _GNU_SOURCE
>>>> +#include <syscall.h>
>>>> +#include <asm/unistd.h>
>>>> +#include <linux/kexec.h>
>>>> +
>>>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>>>> +.fi
>>>> +.in
>>>> +.PP
>>>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>>>> +and later kernels, in earlier kernels the constants need to be copied
>>>> +out of the kernel source.
>>>> +.SH SEE ALSO
>>>> +.BR syscall (2),
>>>> +.BR reboot (2)
>>>> diff --git a/man2/reboot.2 b/man2/reboot.2
>>>> index 253bd34..87204b1 100644
>>>> --- a/man2/reboot.2
>>>> +++ b/man2/reboot.2
>>>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>>>  anything at present (2.1.122), but the type of reboot can be
>>>>  determined by kernel command-line arguments ("reboot=...") to be
>>>>  either warm or cold, and either hard or through the BIOS.
>>>> +.TP
>>>> +.B LINUX_REBOOT_KEXEC
>>>> +executes a kernel that has been loaded earlier
>>>> +with
>>>> +.I kexec_load(2).
>>>>  .SH "RETURN VALUE"
>>>>  For the values of
>>>>  .I cmd
>>>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>>>  .BR capabilities (7),
>>>>  .BR ctrlaltdel (8),
>>>>  .BR halt (8),
>>>> -.BR reboot (8)
>>>> +.BR reboot (8),
>>>> +.BR kexec_load (2)
>>>
>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Author of "The Linux Programming Interface" http://blog.man7.org/
>>
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hey Andi,

I'd like to push this page out the door, but I'm blocked doing so
until I hear back from you regarding the question below (plus a new
version of the page, if needed please).

Thanks,

Michael


On Sat, Sep 11, 2010 at 6:46 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
> Hi Andi,
>
> Ping!
>
> Cheers,
>
> Michael
>
>
> On Sat, Jun 26, 2010 at 3:23 PM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>> Hi Andi,
>>
>> Are Eric's suggestions of "physical" below correct? If so, could you
>> amend the page and resubmit?
>>
>> Also, I'd prefer to have the reboot.2 and kexec_load.2 page as
>> separate patches, so could you split them on the resend please?
>>
>> Thanks,
>>
>> Michael
>>
>> On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Andi Kleen <andi@firstfloor.org> writes:
>>>
>>>> Here are the beginnings of a kexec_load manpage.
>>>>
>>>> Probably needs some more review from Eric and may need some additional
>>>> information.
>>>>
>>>> The syscall is actually only usable with a kernel patch to export
>>>> the header I just sent separately.
>>>
>>> The syscall has been used for years with a separate non-kernel header.
>>>
>>>
>>> Eric
>>>
>>>
>>>> Also added the kexec subcall to reboot(2)
>>>>
>>>> -Andi
>>>>
>>>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>>>> new file mode 100644
>>>> index 0000000..f486641
>>>> --- /dev/null
>>>> +++ b/man2/kexec_load.2
>>>> @@ -0,0 +1,94 @@
>>>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>>>> +.SH NAME
>>>> +kexec_load \- Load a new kernel for later execution.
>>>> +.SH SYNOPSIS
>>>> +.b #include <linux/kexec.h>
>>>> +.br
>>>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>>>> +.br
>>>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>>>> +.SH DESCRIPTION
>>>> +.BR kexec_load
>>>> +loads a new kernel that can be executed later
>>>> +by
>>>> +.I reboot(2).
>>>> +An alternative approach is to specify
>>>> +.B KEXEC_ON_CRASH
>>>> +in the
>>>> +.I flags
>>>> +argument and then the new kernel will be automatically executed on a
>>>> +system crash.
>>>> +.\" XXX figure out how this is really used
>>>> +With
>>>> +.B KEXEC_PRESERVE_CONTEXT
>>>> +specified in
>>>> +.I flags
>>>> +kexec will preserve the system hard and
>>>> +software state before executing the kexec kernel. This
>>>> +could be used for system suspend.
>>>> +
>>>> +.I flags
>>>> +also contains the architecture of the executed kernel or
>>>> +be
>>>> +.I KEXEC_ARCH_DEFAULT
>>>> +for the current architecture.
>>>> +Valid architectures are
>>>> +.I KEXEC_ARCH_I386,
>>>> +.I KEXEC_ARCH_X86_64,
>>>> +.I KEXEC_ARCH_PPC,
>>>> +.I KEXEC_ARCH_PPC64,
>>>> +.I KEXEC_ARCH_IA_64,
>>>> +.I KEXEC_ARCH_ARM,
>>>> +.I KEXEC_ARCH_S390,
>>>> +.I KEXEC_ARCH_SH,
>>>> +.I KEXEC_ARCH_MIPS,
>>>> +.I KEXEC_ARCH_MIPS_LE.
>>>> +The architecture must be executable on the CPU of the system.
>>>> +
>>>> +.I entry
>>>> +is the virtual entry address in the kernel image.
>>>
>>> Physical.
>>>
>>>> +.I nr_segments
>>>> +is the number of segments pointed to by the
>>>> +.I segments
>>>> +pointer.
>>>> +.I segments
>>>> +is an array of
>>>> +.I struct kexec_segment
>>>> +structures which define the kernel layout:
>>>> +.in +4n
>>>> +.nf
>>>> +
>>>> +struct kexec_segment {
>>>> +     void   *buf;    /* Buffer in user space */
>>>> +     size_t  bufsz;  /* Buffer length in user space */
>>>> +     void   *mem;    /* Virtual address of kernel */
>>>> +     size_t  memsz;  /* Virtual address length */
>>>
>>> There are again physical addresses.
>>>
>>> There is an expectation that at hand off from sys_kexec that
>>> virtual and physical addresses will be identity mapped.  But
>>> this isn't the old Alpha booting convention where you have
>>> a virtual address and then you have to parse the page table
>>> to figure out where your kernel was actually loaded.
>>>
>>>> +};
>>>> +.fi
>>>> +.in
>>>> +.PP
>>>> +.\" XXX elaborate on this
>>>> +The kernel image defined by
>>>> +.I segments
>>>> +is copied from the calling process into previously reserved memory.
>>>> +.SH CONFORMING TO
>>>> +This system call is Linux-specific.
>>>> +.SH NOTES
>>>> +kexec_load is currently not defined in glibc. To call it use:
>>>> +.in +4n
>>>> +.nf
>>>> +#define _GNU_SOURCE
>>>> +#include <syscall.h>
>>>> +#include <asm/unistd.h>
>>>> +#include <linux/kexec.h>
>>>> +
>>>> +ret = syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
>>>> +.fi
>>>> +.in
>>>> +.PP
>>>> +.I linux/kexec.h as a exported header is only available in 2.6.38
>>>> +and later kernels, in earlier kernels the constants need to be copied
>>>> +out of the kernel source.
>>>> +.SH SEE ALSO
>>>> +.BR syscall (2),
>>>> +.BR reboot (2)
>>>> diff --git a/man2/reboot.2 b/man2/reboot.2
>>>> index 253bd34..87204b1 100644
>>>> --- a/man2/reboot.2
>>>> +++ b/man2/reboot.2
>>>> @@ -139,6 +139,11 @@ For the i386 architecture, the additional argument does not do
>>>>  anything at present (2.1.122), but the type of reboot can be
>>>>  determined by kernel command-line arguments ("reboot=...") to be
>>>>  either warm or cold, and either hard or through the BIOS.
>>>> +.TP
>>>> +.B LINUX_REBOOT_KEXEC
>>>> +executes a kernel that has been loaded earlier
>>>> +with
>>>> +.I kexec_load(2).
>>>>  .SH "RETURN VALUE"
>>>>  For the values of
>>>>  .I cmd
>>>> @@ -177,4 +182,5 @@ and should not be used in programs intended to be portable.
>>>>  .BR capabilities (7),
>>>>  .BR ctrlaltdel (8),
>>>>  .BR halt (8),
>>>> -.BR reboot (8)
>>>> +.BR reboot (8),
>>>> +.BR kexec_load (2)
>>>
>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Author of "The Linux Programming Interface" http://blog.man7.org/
>>
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> Hey Andi,
> 
> I'd like to push this page out the door, but I'm blocked doing so
> until I hear back from you regarding the question below (plus a new
> version of the page, if needed please).

Probably. Eric should know.

Frankly without an header the syscall is pretty much unusable
for normal programs anyways, so I gave up on this.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> Hey Andi,
> 
> I'd like to push this page out the door, but I'm blocked doing so
> until I hear back from you regarding the question below (plus a new
> version of the page, if needed please).

Probably. Eric should know.

Frankly without an header the syscall is pretty much unusable
for normal programs anyways, so I gave up on this.

-Andi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > Hey Andi,
> > 
> > I'd like to push this page out the door, but I'm blocked doing so
> > until I hear back from you regarding the question below (plus a new
> > version of the page, if needed please).
> 
> Probably. Eric should know.
> 
> Frankly without an header the syscall is pretty much unusable
> for normal programs anyways, so I gave up on this.

I'm not sure that I ever understood the impasse over the header.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > Hey Andi,
> > 
> > I'd like to push this page out the door, but I'm blocked doing so
> > until I hear back from you regarding the question below (plus a new
> > version of the page, if needed please).
> 
> Probably. Eric should know.
> 
> Frankly without an header the syscall is pretty much unusable
> for normal programs anyways, so I gave up on this.

I'm not sure that I ever understood the impasse over the header.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
> On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > > Hey Andi,
> > > 
> > > I'd like to push this page out the door, but I'm blocked doing so
> > > until I hear back from you regarding the question below (plus a new
> > > version of the page, if needed please).
> > 
> > Probably. Eric should know.
> > 
> > Frankly without an header the syscall is pretty much unusable
> > for normal programs anyways, so I gave up on this.
> 
> I'm not sure that I ever understood the impasse over the header.

It's basically: should kexec_load only be used from kexec(8)
or is it a generally available syscall.

If the former is true no header or manpage is needed.
For the later both are.

-Andi
-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Andi Kleen]

On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
> On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > > Hey Andi,
> > > 
> > > I'd like to push this page out the door, but I'm blocked doing so
> > > until I hear back from you regarding the question below (plus a new
> > > version of the page, if needed please).
> > 
> > Probably. Eric should know.
> > 
> > Frankly without an header the syscall is pretty much unusable
> > for normal programs anyways, so I gave up on this.
> 
> I'm not sure that I ever understood the impasse over the header.

It's basically: should kexec_load only be used from kexec(8)
or is it a generally available syscall.

If the former is true no header or manpage is needed.
For the later both are.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Thu, Oct 28, 2010 at 02:25:40PM +0200, Andi Kleen wrote:
> On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
> > On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> > > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > > > Hey Andi,
> > > > 
> > > > I'd like to push this page out the door, but I'm blocked doing so
> > > > until I hear back from you regarding the question below (plus a new
> > > > version of the page, if needed please).
> > > 
> > > Probably. Eric should know.
> > > 
> > > Frankly without an header the syscall is pretty much unusable
> > > for normal programs anyways, so I gave up on this.
> > 
> > I'm not sure that I ever understood the impasse over the header.
> 
> It's basically: should kexec_load only be used from kexec(8)
> or is it a generally available syscall.
> 
> If the former is true no header or manpage is needed.
> For the later both are.

Magnus Damm is interested in having a kexec-tools module for busybox [1].
And I suspect that would be somewhat less tedious to implement
if kexec was a generally available syscall.

[1] http://tree.celinuxforum.org/pipermail/celinux-dev/2010-October/002057.html

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Thu, Oct 28, 2010 at 02:25:40PM +0200, Andi Kleen wrote:
> On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
> > On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
> > > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
> > > > Hey Andi,
> > > > 
> > > > I'd like to push this page out the door, but I'm blocked doing so
> > > > until I hear back from you regarding the question below (plus a new
> > > > version of the page, if needed please).
> > > 
> > > Probably. Eric should know.
> > > 
> > > Frankly without an header the syscall is pretty much unusable
> > > for normal programs anyways, so I gave up on this.
> > 
> > I'm not sure that I ever understood the impasse over the header.
> 
> It's basically: should kexec_load only be used from kexec(8)
> or is it a generally available syscall.
> 
> If the former is true no header or manpage is needed.
> For the later both are.

Magnus Damm is interested in having a kexec-tools module for busybox [1].
And I suspect that would be somewhat less tedious to implement
if kexec was a generally available syscall.

[1] http://tree.celinuxforum.org/pipermail/celinux-dev/2010-October/002057.html


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hi Andi,

On Sat, Jun 19, 2010 at 3:26 PM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> Here are the beginnings of a kexec_load manpage.

Thanks. I have added this page to the set. In another reply, I'll show
some revisions I made to the page.

> Probably needs some more review from Eric and may need some additional
> information.

I will pull Eric's comments into the page.

> The syscall is actually only usable with a kernel patch to export
> the header I just sent separately.

Will this patch make it in?

> Also added the kexec subcall to reboot(2)

Applied.

The changes will be in man-pages 3.30.

Thanks,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hello Eric,

On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>
>> Here are the beginnings of a kexec_load manpage.
>>
>> Probably needs some more review from Eric and may need some additional
>> information.
>>
>> The syscall is actually only usable with a kernel patch to export
>> the header I just sent separately.
>
> The syscall has been used for years with a separate non-kernel header.
>
>
> Eric
>
>
>> Also added the kexec subcall to reboot(2)
>>
>> -Andi
>>
>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>> new file mode 100644
>> index 0000000..f486641
>> --- /dev/null
>> +++ b/man2/kexec_load.2
>> @@ -0,0 +1,94 @@
>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +kexec_load \- Load a new kernel for later execution.
>> +.SH SYNOPSIS
>> +.b #include <linux/kexec.h>
>> +.br
>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>> +.br
>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>> +.SH DESCRIPTION
>> +.BR kexec_load
>> +loads a new kernel that can be executed later
>> +by
>> +.I reboot(2).
>> +An alternative approach is to specify
>> +.B KEXEC_ON_CRASH
>> +in the
>> +.I flags
>> +argument and then the new kernel will be automatically executed on a
>> +system crash.
>> +.\" XXX figure out how this is really used
>> +With
>> +.B KEXEC_PRESERVE_CONTEXT
>> +specified in
>> +.I flags
>> +kexec will preserve the system hard and
>> +software state before executing the kexec kernel. This
>> +could be used for system suspend.
>> +
>> +.I flags
>> +also contains the architecture of the executed kernel or
>> +be
>> +.I KEXEC_ARCH_DEFAULT
>> +for the current architecture.
>> +Valid architectures are
>> +.I KEXEC_ARCH_I386,
>> +.I KEXEC_ARCH_X86_64,
>> +.I KEXEC_ARCH_PPC,
>> +.I KEXEC_ARCH_PPC64,
>> +.I KEXEC_ARCH_IA_64,
>> +.I KEXEC_ARCH_ARM,
>> +.I KEXEC_ARCH_S390,
>> +.I KEXEC_ARCH_SH,
>> +.I KEXEC_ARCH_MIPS,
>> +.I KEXEC_ARCH_MIPS_LE.
>> +The architecture must be executable on the CPU of the system.
>> +
>> +.I entry
>> +is the virtual entry address in the kernel image.
>
> Physical.

Changed.

>> +.I nr_segments
>> +is the number of segments pointed to by the
>> +.I segments
>> +pointer.
>> +.I segments
>> +is an array of
>> +.I struct kexec_segment
>> +structures which define the kernel layout:
>> +.in +4n
>> +.nf
>> +
>> +struct kexec_segment {
>> +     void   *buf;    /* Buffer in user space */
>> +     size_t  bufsz;  /* Buffer length in user space */
>> +     void   *mem;    /* Virtual address of kernel */
>> +     size_t  memsz;  /* Virtual address length */
>
> There are again physical addresses.

Changed.

Thanks,

Michael

> There is an expectation that at hand off from sys_kexec that
> virtual and physical addresses will be identity mapped.  But
> this isn't the old Alpha booting convention where you have
> a virtual address and then you have to parse the page table
> to figure out where your kernel was actually loaded.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Hello Eric,

On Sat, Jun 19, 2010 at 9:18 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andi Kleen <andi@firstfloor.org> writes:
>
>> Here are the beginnings of a kexec_load manpage.
>>
>> Probably needs some more review from Eric and may need some additional
>> information.
>>
>> The syscall is actually only usable with a kernel patch to export
>> the header I just sent separately.
>
> The syscall has been used for years with a separate non-kernel header.
>
>
> Eric
>
>
>> Also added the kexec subcall to reboot(2)
>>
>> -Andi
>>
>> diff --git a/man2/kexec_load.2 b/man2/kexec_load.2
>> new file mode 100644
>> index 0000000..f486641
>> --- /dev/null
>> +++ b/man2/kexec_load.2
>> @@ -0,0 +1,94 @@
>> +.TH KEXEC_LOAD 2 2010-06-16 "Linux" "Linux Programmer's Manual"
>> +.SH NAME
>> +kexec_load \- Load a new kernel for later execution.
>> +.SH SYNOPSIS
>> +.b #include <linux/kexec.h>
>> +.br
>> +.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
>> +.br
>> +.BI       "struct kexec_segment *" segments ", unsigned long " flags ");"
>> +.SH DESCRIPTION
>> +.BR kexec_load
>> +loads a new kernel that can be executed later
>> +by
>> +.I reboot(2).
>> +An alternative approach is to specify
>> +.B KEXEC_ON_CRASH
>> +in the
>> +.I flags
>> +argument and then the new kernel will be automatically executed on a
>> +system crash.
>> +.\" XXX figure out how this is really used
>> +With
>> +.B KEXEC_PRESERVE_CONTEXT
>> +specified in
>> +.I flags
>> +kexec will preserve the system hard and
>> +software state before executing the kexec kernel. This
>> +could be used for system suspend.
>> +
>> +.I flags
>> +also contains the architecture of the executed kernel or
>> +be
>> +.I KEXEC_ARCH_DEFAULT
>> +for the current architecture.
>> +Valid architectures are
>> +.I KEXEC_ARCH_I386,
>> +.I KEXEC_ARCH_X86_64,
>> +.I KEXEC_ARCH_PPC,
>> +.I KEXEC_ARCH_PPC64,
>> +.I KEXEC_ARCH_IA_64,
>> +.I KEXEC_ARCH_ARM,
>> +.I KEXEC_ARCH_S390,
>> +.I KEXEC_ARCH_SH,
>> +.I KEXEC_ARCH_MIPS,
>> +.I KEXEC_ARCH_MIPS_LE.
>> +The architecture must be executable on the CPU of the system.
>> +
>> +.I entry
>> +is the virtual entry address in the kernel image.
>
> Physical.

Changed.

>> +.I nr_segments
>> +is the number of segments pointed to by the
>> +.I segments
>> +pointer.
>> +.I segments
>> +is an array of
>> +.I struct kexec_segment
>> +structures which define the kernel layout:
>> +.in +4n
>> +.nf
>> +
>> +struct kexec_segment {
>> +     void   *buf;    /* Buffer in user space */
>> +     size_t  bufsz;  /* Buffer length in user space */
>> +     void   *mem;    /* Virtual address of kernel */
>> +     size_t  memsz;  /* Virtual address length */
>
> There are again physical addresses.

Changed.

Thanks,

Michael

> There is an expectation that at hand off from sys_kexec that
> virtual and physical addresses will be identity mapped.  But
> this isn't the old Alpha booting convention where you have
> a virtual address and then you have to parse the page table
> to figure out where your kernel was actually loaded.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

On Sat, Jun 19, 2010 at 9:45 PM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
>> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
>>
>> > Here are the beginnings of a kexec_load manpage.
>> >
>> > Probably needs some more review from Eric and may need some additional
>> > information.
>> >
>> > The syscall is actually only usable with a kernel patch to export
>> > the header I just sent separately.
>>
>> The syscall has been used for years with a separate non-kernel header.
>
> Yes but that's not a sane interface that can be documented.

Agreed. Surely the right thing to do is export the proper header?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

On Sat, Jun 19, 2010 at 9:45 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
>> Andi Kleen <andi@firstfloor.org> writes:
>>
>> > Here are the beginnings of a kexec_load manpage.
>> >
>> > Probably needs some more review from Eric and may need some additional
>> > information.
>> >
>> > The syscall is actually only usable with a kernel patch to export
>> > the header I just sent separately.
>>
>> The syscall has been used for years with a separate non-kernel header.
>
> Yes but that's not a sane interface that can be documented.

Agreed. Surely the right thing to do is export the proper header?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Andi, Erric, and all,

On Thu, Oct 28, 2010 at 2:25 PM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
>> On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
>> > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
>> > > Hey Andi,
>> > >
>> > > I'd like to push this page out the door, but I'm blocked doing so
>> > > until I hear back from you regarding the question below (plus a new
>> > > version of the page, if needed please).
>> >
>> > Probably. Eric should know.
>> >
>> > Frankly without an header the syscall is pretty much unusable
>> > for normal programs anyways, so I gave up on this.
>>
>> I'm not sure that I ever understood the impasse over the header.
>
> It's basically: should kexec_load only be used from kexec(8)
> or is it a generally available syscall.
>
> If the former is true no header or manpage is needed.
> For the later both are.

On the other hand, I always think a man page is needed...

Andi, I incorporated Eric's suggestions and made a few other changes:

    Added a license (Andi, I used the verbatim license, and put copyright
    in your name -- okay?)

    Various wording and layout improvements.

    Fixed the name of a constant: s/KEXEC_ARCH_I386/KEXEC_ARCH_386/.

    Added RETURN VALUE and ERRORS sections.
    Added VERSIONS section

    Removed details of using syscall; the reader can find them in syscall(2).

    Added some details for KEXEC_PRESERVE_CONTEXT.

    Revised the text mentioning the kernel header, since it is
    not yet exported, and it's not certain that it will be.

    Note that CONFIG_KEXEC is needed

Review of my changes, and of course Andi's original would be most
welcome. The current version of the page is pushed to git, and inline
below.

Cheers,

Michael


.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (C) 2010 Andi Kleen
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.TH KEXEC_LOAD 2 2010-10-31 "Linux" "Linux Programmer's Manual"
.SH NAME
kexec_load \- load a new kernel for later execution
.SH SYNOPSIS
.b #include <linux/kexec.h>
.br
.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
.br
.BI "                struct kexec_segment *" segments \
", unsigned long " flags ");"
.SH DESCRIPTION
The
.BR kexec_load ()
system call loads a new kernel that can be executed later by
.BR reboot(2) .
.PP
The
.I flags
argument is a mask whose high-order bits control the operation of the call.
The following values can be specified in
.IR flags :
.TP
.B KEXEC_ON_CRASH
Execute the new kernel automatically on a system crash.
.\" FIXME figure out how this is really used
.TP
.B KEXEC_PRESERVE_CONTEXT
Preserve the system hardware and
software states before executing the new kernel.
This could be used for system suspend.
This flag is only available if the kernel was configured with
.BR CONFIG_KEXEC_JUMP ,
and is only effective if
.I nr_segments
is greater than 0.
.PP
The low-order bits of
.I flags
contain the architecture of the to-be-executed kernel.
Specify (OR) the constant
.B KEXEC_ARCH_DEFAULT
to use the current architecture,
or one of the following architecture constants
.BR KEXEC_ARCH_386 ,
.BR KEXEC_ARCH_X86_64 ,
.BR KEXEC_ARCH_PPC ,
.BR KEXEC_ARCH_PPC64 ,
.BR KEXEC_ARCH_IA_64 ,
.BR KEXEC_ARCH_ARM ,
.BR KEXEC_ARCH_S390 ,
.BR KEXEC_ARCH_SH ,
.BR KEXEC_ARCH_MIPS ,
and
.BR KEXEC_ARCH_MIPS_LE .
The architecture must be executable on the CPU of the system.

The
.I entry
argument is the physical entry address in the kernel image.
The
.I nr_segments
argument is the number of segments pointed to by the
.I segments
pointer.
The
.I segments
argument is an array of
.I kexec_segment
structures which define the kernel layout:
.in +4n
.nf

struct kexec_segment {
    void   *buf;        /* Buffer in user space */
    size_t  bufsz;      /* Buffer length in user space */
    void   *mem;        /* Physical address of kernel */
    size_t  memsz;      /* Physical address length */
};
.fi
.in
.PP
.\" FIXME elaborate on the following:
The kernel image defined by
.I segments
is copied from the calling process into previously reserved memory.
.SH RETURN VALUE
On success,
.BR kexec_load ()
returns 0.
On error, -1 is returned and
.I errno
is set to indicate the error.
.SH ERRORS
.TP
.B EBUSY
Another crash kernel is already being loaded
or a crash kernel is already in use.
.TP
.B EINVAL
.I flags
is invalid; of
.IR nr_segments is too large
.\" KEXEC_SEGMENT_MAX == 16
.TP
.B EPERM
The caller does not have the
.BR CAP_SYS_BOOT
capability.
.SH VERSIONS
The
.BR kexec_load ()
system call first appeared in Linux 2.6.7.
.SH CONFORMING TO
This system call is Linux-specific.
.SH NOTES
Currently, there is no glibc support for
.BR kexec_load ().
Call it using
.BR syscall (2).
.PP
The required constants are in the kernel source file
.IR linux/kexec.h ,
which is not currently exported to glibc.
.\" FIXME Andi submitted a patch for this.
.\" Check if it got accepted later.
Therefore, these constants must be defined manually.

This system call is only available if the kernel was configured with
.BR CONFIG_KEXEC .
.SH SEE ALSO
.BR syscall (2),
.BR reboot (2)


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Michael Kerrisk]

Andi, Erric, and all,

On Thu, Oct 28, 2010 at 2:25 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Thu, Oct 28, 2010 at 09:14:17PM +0900, Simon Horman wrote:
>> On Sun, Oct 24, 2010 at 11:38:02PM +0200, Andi Kleen wrote:
>> > On Sun, Oct 24, 2010 at 04:56:24PM +0200, Michael Kerrisk wrote:
>> > > Hey Andi,
>> > >
>> > > I'd like to push this page out the door, but I'm blocked doing so
>> > > until I hear back from you regarding the question below (plus a new
>> > > version of the page, if needed please).
>> >
>> > Probably. Eric should know.
>> >
>> > Frankly without an header the syscall is pretty much unusable
>> > for normal programs anyways, so I gave up on this.
>>
>> I'm not sure that I ever understood the impasse over the header.
>
> It's basically: should kexec_load only be used from kexec(8)
> or is it a generally available syscall.
>
> If the former is true no header or manpage is needed.
> For the later both are.

On the other hand, I always think a man page is needed...

Andi, I incorporated Eric's suggestions and made a few other changes:

    Added a license (Andi, I used the verbatim license, and put copyright
    in your name -- okay?)

    Various wording and layout improvements.

    Fixed the name of a constant: s/KEXEC_ARCH_I386/KEXEC_ARCH_386/.

    Added RETURN VALUE and ERRORS sections.
    Added VERSIONS section

    Removed details of using syscall; the reader can find them in syscall(2).

    Added some details for KEXEC_PRESERVE_CONTEXT.

    Revised the text mentioning the kernel header, since it is
    not yet exported, and it's not certain that it will be.

    Note that CONFIG_KEXEC is needed

Review of my changes, and of course Andi's original would be most
welcome. The current version of the page is pushed to git, and inline
below.

Cheers,

Michael


.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (C) 2010 Andi Kleen
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.TH KEXEC_LOAD 2 2010-10-31 "Linux" "Linux Programmer's Manual"
.SH NAME
kexec_load \- load a new kernel for later execution
.SH SYNOPSIS
.b #include <linux/kexec.h>
.br
.BI "long kexec_load(unsigned long " entry ", unsigned long " nr_segments ","
.br
.BI "                struct kexec_segment *" segments \
", unsigned long " flags ");"
.SH DESCRIPTION
The
.BR kexec_load ()
system call loads a new kernel that can be executed later by
.BR reboot(2) .
.PP
The
.I flags
argument is a mask whose high-order bits control the operation of the call.
The following values can be specified in
.IR flags :
.TP
.B KEXEC_ON_CRASH
Execute the new kernel automatically on a system crash.
.\" FIXME figure out how this is really used
.TP
.B KEXEC_PRESERVE_CONTEXT
Preserve the system hardware and
software states before executing the new kernel.
This could be used for system suspend.
This flag is only available if the kernel was configured with
.BR CONFIG_KEXEC_JUMP ,
and is only effective if
.I nr_segments
is greater than 0.
.PP
The low-order bits of
.I flags
contain the architecture of the to-be-executed kernel.
Specify (OR) the constant
.B KEXEC_ARCH_DEFAULT
to use the current architecture,
or one of the following architecture constants
.BR KEXEC_ARCH_386 ,
.BR KEXEC_ARCH_X86_64 ,
.BR KEXEC_ARCH_PPC ,
.BR KEXEC_ARCH_PPC64 ,
.BR KEXEC_ARCH_IA_64 ,
.BR KEXEC_ARCH_ARM ,
.BR KEXEC_ARCH_S390 ,
.BR KEXEC_ARCH_SH ,
.BR KEXEC_ARCH_MIPS ,
and
.BR KEXEC_ARCH_MIPS_LE .
The architecture must be executable on the CPU of the system.

The
.I entry
argument is the physical entry address in the kernel image.
The
.I nr_segments
argument is the number of segments pointed to by the
.I segments
pointer.
The
.I segments
argument is an array of
.I kexec_segment
structures which define the kernel layout:
.in +4n
.nf

struct kexec_segment {
    void   *buf;        /* Buffer in user space */
    size_t  bufsz;      /* Buffer length in user space */
    void   *mem;        /* Physical address of kernel */
    size_t  memsz;      /* Physical address length */
};
.fi
.in
.PP
.\" FIXME elaborate on the following:
The kernel image defined by
.I segments
is copied from the calling process into previously reserved memory.
.SH RETURN VALUE
On success,
.BR kexec_load ()
returns 0.
On error, -1 is returned and
.I errno
is set to indicate the error.
.SH ERRORS
.TP
.B EBUSY
Another crash kernel is already being loaded
or a crash kernel is already in use.
.TP
.B EINVAL
.I flags
is invalid; of
.IR nr_segments is too large
.\" KEXEC_SEGMENT_MAX == 16
.TP
.B EPERM
The caller does not have the
.BR CAP_SYS_BOOT
capability.
.SH VERSIONS
The
.BR kexec_load ()
system call first appeared in Linux 2.6.7.
.SH CONFORMING TO
This system call is Linux-specific.
.SH NOTES
Currently, there is no glibc support for
.BR kexec_load ().
Call it using
.BR syscall (2).
.PP
The required constants are in the kernel source file
.IR linux/kexec.h ,
which is not currently exported to glibc.
.\" FIXME Andi submitted a patch for this.
.\" Check if it got accepted later.
Therefore, these constants must be defined manually.

This system call is only available if the kernel was configured with
.BR CONFIG_KEXEC .
.SH SEE ALSO
.BR syscall (2),
.BR reboot (2)


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Sun, Oct 31, 2010 at 07:19:58AM +0100, Michael Kerrisk wrote:
> On Sat, Jun 19, 2010 at 9:45 PM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> > On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
> >> Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> writes:
> >>
> >> > Here are the beginnings of a kexec_load manpage.
> >> >
> >> > Probably needs some more review from Eric and may need some additional
> >> > information.
> >> >
> >> > The syscall is actually only usable with a kernel patch to export
> >> > the header I just sent separately.
> >>
> >> The syscall has been used for years with a separate non-kernel header.
> >
> > Yes but that's not a sane interface that can be documented.
> 
> Agreed. Surely the right thing to do is export the proper header?

I am in favour of that option.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kexec_load manpage

[Simon Horman]

On Sun, Oct 31, 2010 at 07:19:58AM +0100, Michael Kerrisk wrote:
> On Sat, Jun 19, 2010 at 9:45 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > On Sat, Jun 19, 2010 at 12:18:52PM -0700, Eric W. Biederman wrote:
> >> Andi Kleen <andi@firstfloor.org> writes:
> >>
> >> > Here are the beginnings of a kexec_load manpage.
> >> >
> >> > Probably needs some more review from Eric and may need some additional
> >> > information.
> >> >
> >> > The syscall is actually only usable with a kernel patch to export
> >> > the header I just sent separately.
> >>
> >> The syscall has been used for years with a separate non-kernel header.
> >
> > Yes but that's not a sane interface that can be documented.
> 
> Agreed. Surely the right thing to do is export the proper header?

I am in favour of that option.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec