mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Bastian Krause <bst@pengutronix.de>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>, barebox@lists.infradead.org
Subject: Re: [PATCH v4 0/4] Machine ID Support
Date: Mon, 30 Sep 2019 20:39:27 +0200	[thread overview]
Message-ID: <20190930183927.lyhrevjbd7i455ce@pengutronix.de> (raw)
In-Reply-To: <20190927095954.13168-1-bst@pengutronix.de>

On Fri, Sep 27, 2019 at 11:59:50AM +0200, Bastian Krause wrote:
> By default systemd generates a machine id on first boot and tries to
> persist it (see `man machine-id`). When the root file system is read-only
> systemd cannot persist the machine id. In case multiple redundant slots
> are used the machine id will vary. When not handled explicitly the
> machine id will also change during system updates.
> 
> It is possible to pass a machine id to the kernel which will be used by
> systemd (systemd.machine_id=).
> 
> This series adds a way to provide device-specific hashable information
> to generate a unique, persistent id. The i.MX unique id from the OCOTP
> registers is added as hashable exemplarily. The id is available as
> global.machine_id in barebox. It can be overwritten with nv.machine_id
> if necessary.
> The machine id is passed on to the Kernel by bootm based on
> global.bootm.provide_machine_id.
> 
> Changes since v3:
>   - nvmem: ocotp: use existing OCOTP_UNIQUE_ID instead of introducing a
>     new define
>   - convert imx_ocotp_set_unique_machine_id() to void as it's return
>     is not used, simplify it
> 
> Changes since v2:
>   - set id to global.machine_id in init call instead of preparing the
>     bootarg already (so it's usable within barebox, too)
>   - move global.linux.bootargs.machine_id preparations to bootm code
>   - make global.linux.bootargs.machine_id preparations conditionally,
>     based on bootm.provide_machine_id
>   - free machine id char pointer after globalvar_add_simple()
>   - make global.machine_id a magicvar
>   - make global.bootm.provide_machine_id a magicvar
> 
> Changes since (implicit) v1:
>   - depend on SHA1 instead of selecting DIGEST/DIGEST_SHA1_GENERIC
>   - add note about multiple sources providing hashables to kconfig
>   - add note about no hashable provided to kconfig
>   - remove warning about "no hashable info provided" along with pr_fmt
>   - make machine_id_set_hashable()'s hashable parameter const
>   - make a copy of the hashable provided rather than storing the pointer
>   - hash data instead of pointer address
>   - use basprintf() and dedicated variables for hex machine id/machine id
>     bootarg
>   - add static inline wrapper if CONFIG_MACHINE_ID is disabled
>   - nvmem: ocotp: remove explicit address-of operator for unique_id_parts
> 
> Regards,
> Bastian
> 
> Bastian Krause (3):
>   common: machine_id: introduce machine id generation
>   nvmem: ocotp: set unique id as machine-id hashable
>   bootm: allow providing machine id to Kernel

Applied, thanks

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      parent reply	other threads:[~2019-09-30 18:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27  9:59 Bastian Krause
2019-09-27  9:59 ` [PATCH v4 1/4] digest.h: needs errno definitions Bastian Krause
2019-09-27  9:59 ` [PATCH v4 2/4] common: machine_id: introduce machine id generation Bastian Krause
2019-09-27  9:59 ` [PATCH v4 3/4] nvmem: ocotp: set unique id as machine-id hashable Bastian Krause
2019-09-27  9:59 ` [PATCH v4 4/4] bootm: allow providing machine id to Kernel Bastian Krause
2019-09-30 18:39 ` Sascha Hauer [this message]

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=20190930183927.lyhrevjbd7i455ce@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=bst@pengutronix.de \
    /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