Re: [bitbake-devel] [RFC PATCH 2/2] bitbake-setup: share sstate by default between builds

["Antonin Godard" <antonin.godard@bootlin.com>]

Hi,

On Mon Dec 15, 2025 at 3:54 PM CET, Alexander Kanavin via lists.openembedded.org wrote:
> From: Alexander Kanavin <alex@linutronix.de>
>
> Nowadays sharing sstate must also include sharing the hash equivalency
> information and thus, managing a hash equivalency server. There are
> two ways to do it:
>
> - starting/stopping the server outside the bitbake invocations, and
> guaranteeing that it's available when bitbake is invoked.
>
> - using bitbake's built-in start/stop code which launches a server
> before a build starts and stops it when a build is finished; essentially
> this is a private server, using a database private to a build directory
> (by default).
>
> I couldn't come up with a good way to do the first option in bitbake-setup:
> it needs to be invisible to users, they should not have to run special commands
> and they should not wonder why there is a mysterious background process.
> It's not impossible to auto-start a shared server, but that will quickly
> run into synchronization issues: if one server is being started, another
> should not be started at the same time. If one server is shutting down
> (e.g. after an inactivity timeout), another starting server should wait
> until it frees the socket, and block all bitbake invocations on that.
> Memory resident bitbake does this in lib/bb/server/process.py with a lot of
> complexity, and I don't think it should be added to the hash server as well.
>
> On the other hand, hash equivalency database is sqlite-driven, and sqlite
> documentation reassures that sharing it between different simultaneous
> processes is okay: nothing will get lost or corrupted: https://sqlite.org/faq.html#q5
>
> I've confirmed this by running simultaneous builds that way: nothing
> unusual happened, and sstate was shared as it's supposed to.
>
> There's a new setting that turns off this behavior for situations
> where the server and sstate are managed externally.
>
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  bin/bitbake-setup | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/bin/bitbake-setup b/bin/bitbake-setup
> index 6f7dba16c..f382f6eb0 100755
> --- a/bin/bitbake-setup
> +++ b/bin/bitbake-setup
> @@ -777,6 +777,12 @@ def create_siteconf(top_dir, non_interactive, settings):
>  
>          os.makedirs(top_dir, exist_ok=True)
>          with open(siteconfpath, 'w') as siteconffile:
> +            sstate_settings = textwrap.dedent(
> +                """
> +                SSTATE_DIR = "{sstate_dir}"
> +                BB_HASHSERVE_DB_DIR = "{sstate_dir}"

Like DL_DIR, it would be nice to add a comment to explain what these variables
do.

Maybe needs some rework but something like this (adapted from poky's template
files):

```
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
SSTATE_DIR = "{sstate_dir}"

# Hash Equivalence database location
#
# Hash equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact. This variable controls where the
# Hash Equivalence database ("hashserv.db") is stored and can be shared between
# concurrent builds.
BB_HASHSERVE_DB_DIR = "{sstate_dir}"
```

We would probably also need an sstate-dir setting, like dl-dir?

FWIW, I've tested this locally and it works as expected but I did not run
concurrent builds.

Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com