From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Arnd Bergmann <arnd@arndb.de>, Baoquan He <bhe@redhat.com>,
Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Vivek Goyal <vgoyal@redhat.com>,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
David Laight <David.Laight@aculab.com>,
Eric Biederman <ebiederm@xmission.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/2] extend kexec_file_load system call
Date: Tue, 30 Aug 2016 20:25:08 -0300 [thread overview]
Message-ID: <2408856.dZN5fLyePL@hactar> (raw)
In-Reply-To: <20160818102112.GB27045@leverpostej>
Hello Mark,
Sorry for taking this long to respond. I've been focusing on getting my
kexec_file_load and kexec buffer hand-over series in shape.
Am Donnerstag, 18 August 2016, 11:21:13 schrieb Mark Rutland:
> On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote:
> > Device tree blob must be passed to a second kernel on DTB-capable
> > archs, like powerpc and arm64, but the current kernel interface
> > lacks this support.
> >
> > This patch extends kexec_file_load system call by adding an extra
> > argument to this syscall so that an arbitrary number of file descriptors
> > can be handed out from user space to the kernel.
> >
> > See the background [1].
> >
> > Please note that the new interface looks quite similar to the current
> > system call, but that it won't always mean that it provides the "binary
> > compatibility."
> >
> > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html
>
> As with the original posting, I have a number of concerns, and I'm
> really not keen on this.
Thanks for laying out out the reasons for your objection. That's very
helpful.
> * For typical usecases, I do not believe that this is necessary (at
> least for arm64), and generally do not believe that it should be
> necessary for a user to manipulate the DTB (much like the user need
> not manipulate ACPI tables or other FW data structures).
>
> Other than (potentially) the case of Linux as a flashed-in bootloader,
> I don't see a compelling case for modifying the DTB that could not be
> accomplished in-kernel. For that case, if truly necessary, I think
> that we can get away with something simpler.
Yes, this is the case I am aiming for. I'll experiment with a couple of
different approaches and see how well they perform.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Baoquan He <bhe@redhat.com>,
David Laight <David.Laight@aculab.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Stewart Smith <stewart@linux.vnet.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 0/2] extend kexec_file_load system call
Date: Tue, 30 Aug 2016 20:25:08 -0300 [thread overview]
Message-ID: <2408856.dZN5fLyePL@hactar> (raw)
In-Reply-To: <20160818102112.GB27045@leverpostej>
Hello Mark,
Sorry for taking this long to respond. I've been focusing on getting my
kexec_file_load and kexec buffer hand-over series in shape.
Am Donnerstag, 18 August 2016, 11:21:13 schrieb Mark Rutland:
> On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote:
> > Device tree blob must be passed to a second kernel on DTB-capable
> > archs, like powerpc and arm64, but the current kernel interface
> > lacks this support.
> >
> > This patch extends kexec_file_load system call by adding an extra
> > argument to this syscall so that an arbitrary number of file descriptors
> > can be handed out from user space to the kernel.
> >
> > See the background [1].
> >
> > Please note that the new interface looks quite similar to the current
> > system call, but that it won't always mean that it provides the "binary
> > compatibility."
> >
> > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html
>
> As with the original posting, I have a number of concerns, and I'm
> really not keen on this.
Thanks for laying out out the reasons for your objection. That's very
helpful.
> * For typical usecases, I do not believe that this is necessary (at
> least for arm64), and generally do not believe that it should be
> necessary for a user to manipulate the DTB (much like the user need
> not manipulate ACPI tables or other FW data structures).
>
> Other than (potentially) the case of Linux as a flashed-in bootloader,
> I don't see a compelling case for modifying the DTB that could not be
> accomplished in-kernel. For that case, if truly necessary, I think
> that we can get away with something simpler.
Yes, this is the case I am aiming for. I'll experiment with a couple of
different approaches and see how well they perform.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: bauerman@linux.vnet.ibm.com (Thiago Jung Bauermann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/2] extend kexec_file_load system call
Date: Tue, 30 Aug 2016 20:25:08 -0300 [thread overview]
Message-ID: <2408856.dZN5fLyePL@hactar> (raw)
In-Reply-To: <20160818102112.GB27045@leverpostej>
Hello Mark,
Sorry for taking this long to respond. I've been focusing on getting my
kexec_file_load and kexec buffer hand-over series in shape.
Am Donnerstag, 18 August 2016, 11:21:13 schrieb Mark Rutland:
> On Thu, Aug 11, 2016 at 08:03:56PM -0300, Thiago Jung Bauermann wrote:
> > Device tree blob must be passed to a second kernel on DTB-capable
> > archs, like powerpc and arm64, but the current kernel interface
> > lacks this support.
> >
> > This patch extends kexec_file_load system call by adding an extra
> > argument to this syscall so that an arbitrary number of file descriptors
> > can be handed out from user space to the kernel.
> >
> > See the background [1].
> >
> > Please note that the new interface looks quite similar to the current
> > system call, but that it won't always mean that it provides the "binary
> > compatibility."
> >
> > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html
>
> As with the original posting, I have a number of concerns, and I'm
> really not keen on this.
Thanks for laying out out the reasons for your objection. That's very
helpful.
> * For typical usecases, I do not believe that this is necessary (at
> least for arm64), and generally do not believe that it should be
> necessary for a user to manipulate the DTB (much like the user need
> not manipulate ACPI tables or other FW data structures).
>
> Other than (potentially) the case of Linux as a flashed-in bootloader,
> I don't see a compelling case for modifying the DTB that could not be
> accomplished in-kernel. For that case, if truly necessary, I think
> that we can get away with something simpler.
Yes, this is the case I am aiming for. I'll experiment with a couple of
different approaches and see how well they perform.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
next prev parent reply other threads:[~2016-08-30 23:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 23:03 [PATCH v2 0/2] extend kexec_file_load system call Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-11 23:03 ` [PATCH v2 1/2] kexec: add dtb info to struct kimage Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-18 8:23 ` Dave Young
2016-08-18 8:23 ` Dave Young
2016-08-18 8:23 ` Dave Young
2016-08-11 23:03 ` [PATCH v2 2/2] kexec: extend kexec_file_load system call Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-11 23:03 ` Thiago Jung Bauermann
2016-08-12 8:17 ` Balbir Singh
2016-08-12 8:17 ` Balbir Singh
2016-08-12 8:17 ` Balbir Singh
2016-08-12 21:44 ` Thiago Jung Bauermann
2016-08-12 21:44 ` Thiago Jung Bauermann
2016-08-12 21:44 ` Thiago Jung Bauermann
2016-08-16 0:13 ` Thiago Jung Bauermann
2016-08-16 0:13 ` Thiago Jung Bauermann
2016-08-16 0:13 ` Thiago Jung Bauermann
2016-08-18 8:19 ` Dave Young
2016-08-18 8:19 ` Dave Young
2016-08-18 8:19 ` Dave Young
2016-08-30 23:34 ` Thiago Jung Bauermann
2016-08-30 23:34 ` Thiago Jung Bauermann
2016-08-30 23:34 ` Thiago Jung Bauermann
2016-08-18 10:21 ` [PATCH v2 0/2] " Mark Rutland
2016-08-18 10:21 ` Mark Rutland
2016-08-18 10:21 ` Mark Rutland
2016-08-30 23:25 ` Thiago Jung Bauermann [this message]
2016-08-30 23:25 ` Thiago Jung Bauermann
2016-08-30 23:25 ` Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2408856.dZN5fLyePL@hactar \
--to=bauerman@linux.vnet.ibm.com \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mpe@ellerman.id.au \
--cc=stewart@linux.vnet.ibm.com \
--cc=takahiro.akashi@linaro.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.