Hi Samuel,
Thanks for your response.
Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
quoted
I have a question about the petitboot feature which allows the user to
specify a device tree blob to pass to the target OS being loaded. What
is
the use case for it? Is it a debugging and development aid, or do you
expect it be useful in a production environment?
Passing the dtb isn't really a Petitboot feature, rather part of how
kexec works for PowerPC and ARM. Petitboot may make modifications to, or
replace the dtb, but the method via with the target kernel obtains its
device-tree is kexec. So I suspect you would have to say it is mandatory
for production.
Right. I already have a working kexec_file_load implementation [1], and what
I'm doing in my patch set is taking the device tree that was used to boot
the current kernel and modifying it as necessary to pass it to the next
kernel.
My question is: is there any need in a production environment for userspace
to provide a different device tree for the next kernel, or can the currently
running kernel always use the device tree that it received when it was
booted?
So one new piece of information for me is that Petitboot makes modifications
to the dtb. Does it do that only if the system administrator provided a
custom dtb (either via the boot options screen or a configuration file), or
can it change/replace the dtb even if the system administrator didn't
provide a custom dtb? Which modifications does Petitboot make?
quoted
I ask this because I'm implementing the kexec_file_load system call for
powerpc, and given its prototype:
long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
cmdline_len, const char *cmdline_ptr, unsigned long flags)
It wouldn't be very straightforward to allow the caller to specify a
device tree blob, so I have to ask how necessary such a feature is.
Yep, I think the problem is kexec_file_load was first implemented with a
focus on x86 where this isn't an issue, and now we need to consider what
to do :)
Yes, that's true. I was able to make it work on powerpc even with that x86
bias, but now I'm wondering if that's enough or not.
We are definitely going to need a way to pass the device-tree to the
target kernel - whether we do that by changing the prototype for
kexec_file_load() PowerPC and ARM, or by dealing with it some other way
I'm not sure.
Do you say definitely because the kexec'd kernel needs to be passed a device
tree, or is it because userspace needs to have some control over the device
tree that the kexec'd kernel receives?
Sounds like the start of a interesting conversation on the
linuxppc-dev list :)
Indeed. :-) I'm copying linuxppc-dev here just in case.
A conversation about this just started in the kexec mailing list (I'm
copying the linuxppc-dev mailing list in my response as well):
https://lists.infradead.org/pipermail/kexec/2016-July/016279.html
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144658.html
On Fri, 2016-07-01 at 13:15 -0300, Thiago Jung Bauermann wrote:
Hi Samuel,
Thanks for your response.
Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
quoted
On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
quoted
I have a question about the petitboot feature which allows the user to
specify a device tree blob to pass to the target OS being loaded. What
is
the use case for it? Is it a debugging and development aid, or do you
expect it be useful in a production environment?
Passing the dtb isn't really a Petitboot feature, rather part of how
kexec works for PowerPC and ARM. Petitboot may make modifications to, or
replace the dtb, but the method via with the target kernel obtains its
device-tree is kexec. So I suspect you would have to say it is mandatory
for production.
Right. I already have a working kexec_file_load implementation [1], and what
I'm doing in my patch set is taking the device tree that was used to boot
the current kernel and modifying it as necessary to pass it to the next
kernel.
Ah ok - I skimmed over the series but didn't notice that, great!
My question is: is there any need in a production environment for userspace
to provide a different device tree for the next kernel, or can the currently
running kernel always use the device tree that it received when it was
booted?
So one new piece of information for me is that Petitboot makes modifications
to the dtb. Does it do that only if the system administrator provided a
custom dtb (either via the boot options screen or a configuration file), or
can it change/replace the dtb even if the system administrator didn't
provide a custom dtb? Which modifications does Petitboot make?
For the next kernel it's sufficient just to have the device-tree, but
Petitboot does make modifications to it to help the next kernel in
certain ways, for example:
- Sorting the device-tree properly if
firmware hasn't done so
- Setting framebuffer information on
OpenPOWER machines
- Setting the primary stdout for the next
kernel
These aren't required for *booting*, but a number of people might start shouting if they go away.
quoted
quoted
I ask this because I'm implementing the kexec_file_load system call for
powerpc, and given its prototype:
long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
cmdline_len, const char *cmdline_ptr, unsigned long flags)
It wouldn't be very straightforward to allow the caller to specify a
device tree blob, so I have to ask how necessary such a feature is.
Yep, I think the problem is kexec_file_load was first implemented with a
focus on x86 where this isn't an issue, and now we need to consider what
to do :)
Yes, that's true. I was able to make it work on powerpc even with that x86
bias, but now I'm wondering if that's enough or not.
quoted
We are definitely going to need a way to pass the device-tree to the
target kernel - whether we do that by changing the prototype for
kexec_file_load() PowerPC and ARM, or by dealing with it some other way
I'm not sure.
Do you say definitely because the kexec'd kernel needs to be passed a device
tree, or is it because userspace needs to have some control over the device
tree that the kexec'd kernel receives?
As above the 'definitely' comes from the kexec'd kernel needing to be
passed a device-tree, as well as some updates made by userspace.
quoted
Sounds like the start of a interesting conversation on the
linuxppc-dev list :)
Indeed. :-) I'm copying linuxppc-dev here just in case.
A conversation about this just started in the kexec mailing list (I'm
copying the linuxppc-dev mailing list in my response as well):
https://lists.infradead.org/pipermail/kexec/2016-July/016279.html
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144658.html