From: andre.przywara@linaro.org (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [PROPOSAL] ARM/FDT: passing multiple binaries to a kernel
Date: Wed, 04 Sep 2013 11:14:08 +0200 [thread overview]
Message-ID: <5226F9E0.9070307@linaro.org> (raw)
In-Reply-To: <1378284955.17510.64.camel@kazak.uk.xensource.com>
On 09/04/2013 10:55 AM, Ian Campbell wrote:
> On Wed, 2013-09-04 at 10:43 +0200, Andre Przywara wrote:
>
>> I am about to write up a more elaborate technical rationale describing
>> the problems with multiboot on ARM:
>>
>> https://wiki.linaro.org/AndrePrzywara/Multiboot
>
> Doesn't seem to exist? A search for "mulitboot" doesn't seem to throw up
> the one you meant either.
Try again now. As mentioned "I am about to write ..." ;-)
Thanks,
Andre.
>>> So, is having a more generic solution really needed?
>>
>> Not necessarily needed, but useful, I think. As described above I don't
>> see any technical obstacles of doing it in a more generic way, so we
>> could as well go ahead with this. On x86 from time to time the need for
>> additional binaries pops up (early microcode loading, for instance), so
>> why not be be prepared.
>
> I agree. There have also been occasions where people doing
> disaggregation have wanted to start multiple initial domains, requiring
> additional modules at load time. I don't think being generic and
> extensible is costing too much here.
>
> Ian.
>
WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
boot-architecture-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
Julien Grall
<julien.grall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"xen-devel-GuqFBffKawuEi8DpZVb4nw@public.gmane.org"
<xen-devel-GuqFBffKawuEi8DpZVb4nw@public.gmane.org>,
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PROPOSAL] ARM/FDT: passing multiple binaries to a kernel
Date: Wed, 04 Sep 2013 11:14:08 +0200 [thread overview]
Message-ID: <5226F9E0.9070307@linaro.org> (raw)
In-Reply-To: <1378284955.17510.64.camel-ommiHX4a84BXesXXhkcM7miJhflN2719@public.gmane.org>
On 09/04/2013 10:55 AM, Ian Campbell wrote:
> On Wed, 2013-09-04 at 10:43 +0200, Andre Przywara wrote:
>
>> I am about to write up a more elaborate technical rationale describing
>> the problems with multiboot on ARM:
>>
>> https://wiki.linaro.org/AndrePrzywara/Multiboot
>
> Doesn't seem to exist? A search for "mulitboot" doesn't seem to throw up
> the one you meant either.
Try again now. As mentioned "I am about to write ..." ;-)
Thanks,
Andre.
>>> So, is having a more generic solution really needed?
>>
>> Not necessarily needed, but useful, I think. As described above I don't
>> see any technical obstacles of doing it in a more generic way, so we
>> could as well go ahead with this. On x86 from time to time the need for
>> additional binaries pops up (early microcode loading, for instance), so
>> why not be be prepared.
>
> I agree. There have also been occasions where people doing
> disaggregation have wanted to start multiple initial domains, requiring
> additional modules at load time. I don't think being generic and
> extensible is costing too much here.
>
> Ian.
>
next prev parent reply other threads:[~2013-09-04 9:14 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 15:53 [PROPOSAL] ARM/FDT: passing multiple binaries to a kernel Andre Przywara
2013-09-03 15:53 ` Andre Przywara
2013-09-03 22:00 ` Rob Herring
2013-09-03 22:00 ` Rob Herring
2013-09-04 8:43 ` Andre Przywara
2013-09-04 8:43 ` Andre Przywara
2013-09-04 8:43 ` Andre Przywara
2013-09-04 8:55 ` Ian Campbell
2013-09-04 8:55 ` Ian Campbell
2013-09-04 8:55 ` Ian Campbell
2013-09-04 9:14 ` Andre Przywara
2013-09-04 9:14 ` Andre Przywara [this message]
2013-09-04 9:14 ` Andre Przywara
2013-09-05 13:23 ` Rob Herring
2013-09-05 13:23 ` Rob Herring
2013-09-05 13:23 ` Rob Herring
2013-09-06 13:30 ` Andre Przywara
2013-09-06 13:30 ` Andre Przywara
2013-09-06 13:30 ` Andre Przywara
2013-09-04 8:44 ` Ian Campbell
2013-09-04 8:44 ` Ian Campbell
2013-09-04 16:41 ` Rob Herring
2013-09-04 16:41 ` Rob Herring
2013-09-13 10:13 ` Grant Likely
2013-09-13 10:13 ` Grant Likely
2013-09-13 10:13 ` Grant Likely
2013-09-13 11:22 ` Ian Campbell
2013-09-13 11:22 ` Ian Campbell
2013-09-13 11:22 ` Ian Campbell
2013-09-15 12:17 ` Grant Likely
2013-09-15 12:17 ` Grant Likely
2013-09-14 1:40 ` Rob Herring
2013-09-14 1:40 ` Rob Herring
2013-09-14 1:40 ` Rob Herring
2013-09-15 12:23 ` Grant Likely
2013-09-15 12:23 ` Grant Likely
2013-09-14 4:06 ` Dennis Gilmore
2013-09-14 4:06 ` Dennis Gilmore
2013-09-14 4:06 ` Dennis Gilmore
2013-09-04 16:41 ` Rob Herring
2013-09-04 8:44 ` Ian Campbell
2013-09-03 22:00 ` Rob Herring
2013-09-15 12:37 ` Grant Likely
2013-09-15 12:37 ` Grant Likely
2013-09-16 17:01 ` Andre Przywara
2013-09-16 17:01 ` Andre Przywara
2013-09-16 17:01 ` Andre Przywara
-- strict thread matches above, loose matches on Subject: below --
2013-09-03 15:53 Andre Przywara
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=5226F9E0.9070307@linaro.org \
--to=andre.przywara@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.