From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] package/jailhouse: add option to choose custom repo/branch
Date: Mon, 1 Jun 2020 23:19:02 +0200 [thread overview]
Message-ID: <20200601211902.GI8737@scaer> (raw)
In-Reply-To: <CAH3JsOrGo0k4S=VKfaXFbgkOv2jYvCB6nff0f+TihKz-1ok4JQ@mail.gmail.com>
Mario, Ralf, All,
On 2020-06-01 18:23 +0200, Mario Mintel spake thusly:
> Am Sa., 30. Mai 2020 um 19:28?Uhr schrieb Mario Mintel < [1]mariomintel@gmail.com>:
> Am Fr., 29. Mai 2020 um 23:40?Uhr schrieb Ralf Ramsauer < [2]ralf.ramsauer@oth-regensburg.de>:
> On 5/29/20 10:48 PM, Yann E. MORIN wrote:
> > Mario, All,
> > On 2020-05-28 16:43 +0200, Mario Mintel spake thusly:
> >> In addition to official releases of Jailhouse, allow to specify a custom
> >> Git URI + branches. This adds more flexibility for custom
> >> configurations.
> > The overwhelming majority of packages do not allow selecting an
> > alternate location. Why would jailhouse be different?
>
> Jailhouse requires system-specific configurations. Those configurations
> are compiled from C source files to binaries during the build process.
> While upstream Jailhouse comes with a lot of samples for supported
> systems, you will need a lot of fine tuning to for a specific use case.
I am not sure I entirely followed... Note that I am totally ignorant to
how jailhouse works (and I barely know what it is). So I had a quick
look into the github repo, and I noticed this:
A system configuration can be created on an x86 target system by
running the following command:
jailhouse config create sysconfig.c
In order to translate this into the required binary form, place
this file in the configs/x86/ directory. The build system will pick
up every .c file from there and generate a corresponding .cell file.
Is this what you were trying to explain?
If so, then I think we need a way for people to indeed provide their
cells descriptions files, so that they do get compiled by jailhouse,
without resorting to using an OVERRDIE_SRCDIR.
So I see a few options:
1- let people provide those .c files as a patch against jailhouse. This
requires no infra in Buildroot, but this is not very convenient;
2- add a configuration option in jailhouse/Config.in, which people
could set as a path to a directory with .c files; those would be
copied into the jailhouse build directory before the actual build,
so the documented way (see above) will be used; those files would
have to be in a br2-external tree or whatever, but not in a package
(because we'd have no way to ensure that package be extracted before
jailhouse gets built).
3- let people write their own package(s) (e.g. in a br2-external tree)
that only builds the cell files. That package would depend on
jailhouse (or rather, the to-be-introduced host-jailhouse). And
packages could also provide their own cell definitions, too...
I think option 3 is the best solution, as it is the most flexible and
most generic one. However, it will depend on the possibility to
introduce a host-jailhoue package that can just install the 'jailhouse
cell cross compiler'. As far as I see, this is just a bunch of objcopy,
but this is quite tightly integrated into the kernel Kbiuld process, so
might not so simple to come up with.
Option 2 is probably a good compromise if option 3 turns out to be too
difficult to come up with...
[--SNIP--]
> It does work as proposed by Yann. I wasn't aware of that option. I
> guess that makes this patch redundant.
Using a completely separate tree? Yes, I think this is not an option.
However, given the above, maybe we still need a way for people to
provide their cells descriptions and have them somehow copied at build
(or configure) time...
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2020-06-01 21:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 14:43 [Buildroot] [PATCH 0/2] Extend Jailhouse package with custom repo option Mario Mintel
2020-05-28 14:43 ` [Buildroot] [PATCH 1/2] package/jailhouse: bump version to 0.12 Mario Mintel
2020-06-06 21:58 ` Thomas Petazzoni
2020-05-28 14:43 ` [Buildroot] [PATCH 2/2] package/jailhouse: add option to choose custom repo/branch Mario Mintel
2020-05-29 20:48 ` Yann E. MORIN
[not found] ` <3806f122-f6b0-efba-e94a-64a3729fbe8a@oth-regensburg.de>
2020-05-30 17:28 ` Mario Mintel
2020-06-01 16:23 ` Mario Mintel
2020-06-01 21:19 ` Yann E. MORIN [this message]
[not found] ` <8ede0323-ef3b-a405-81dc-80f92085ab93@oth-regensburg.de>
2020-06-02 10:53 ` Jan Kiszka
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=20200601211902.GI8737@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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.