From: Andreas Schmidt <mail@schmidt-andreas.de>
To: barebox@lists.infradead.org
Subject: Re: [PATCH] blspec: add checking of optional key machine-id
Date: Thu, 3 May 2018 10:42:49 +0200 [thread overview]
Message-ID: <9451da5b-d585-34cc-9d4d-c2645329b760@schmidt-andreas.de> (raw)
In-Reply-To: <1525271572.17782.13.camel@pengutronix.de>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1909 bytes --]
Hallo Jan,
On 02.05.2018 16:32, Jan Lübbe wrote:
> On Sun, 2018-04-29 at 18:01 +0200, Andreas Schmidt wrote:
>> I guess, for such an use case Bootloader Spec specify "machine-id"
>> key. This patch implement the support for machine-id key.
> The way I read https://www.freedesktop.org/wiki/Specifications/BootLoad
> erSpec/ is that the "machine-id" field should contain the ID from
> /etc/machine-id, which is basically a UUID:
> "machine-id shall contain the machine ID of the OS /etc/machine-id.
> This is useful for boot loaders and applications to filter out boot
> entries, for example to show only a single newest kernel per OS, or to
> group items by OS, or to maybe filter out the currently booted OS in
> UIs that want to show only other installed operating systems."
I read this part in same way. I think, the patch isn't in conflict with
that. And, yes, you're right we would use it not exact in this way.
Out /etc/machine-id is building dynamically and would be the same as barebox
choose one. (Same way to set global.boot.machine_id and content of
/etc/machine-id)
But, all our FW would have different machine-id in dependent of devices
and not on
OS.
The spec says: "for example to show only ...". So I guess, it is not
hard requirement.
Was I'm wrong?
> Your use-case sound like you'd need a way to add a more specific DT
> board compatible at runtime.
We need a decision witch DT has to be load at runtime. But they are all
compatible with the barebox DT. We have only one barebox DT for all devices.
> Then the existing selection logic would
> handle your case as well.
Ohh ... ok. And could you explain please, who we could do that? Because,
all our DTs are compatible with barebox DT and barebox would choose simple
the first one and boot it. Or is using of Bootloader Spec isn't right
way, to solve
this issue?
Regards,
Andreas
[-- Attachment #1.1.1.2: 0xFEE0A611BEA6DEA0.asc --]
[-- Type: application/pgp-keys, Size: 3133 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-05-03 8:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-29 16:01 Andreas Schmidt
2018-05-02 11:02 ` Sascha Hauer
2018-05-02 13:23 ` [PATCH v2] " Andreas Schmidt
2018-05-08 6:13 ` Sascha Hauer
2018-05-02 14:32 ` [PATCH] " Jan Lübbe
2018-05-03 8:42 ` Andreas Schmidt [this message]
2018-05-03 9:34 ` Jan Lübbe
2018-05-03 15:31 ` Andreas Schmidt
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=9451da5b-d585-34cc-9d4d-c2645329b760@schmidt-andreas.de \
--to=mail@schmidt-andreas.de \
--cc=barebox@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox