Skip to content

Conversation

@aescolar
Copy link
Member

Support using FUSE v3, instead of FUSE v2.

FUSE v3 has been out for a couple of years now, so most distributions
have it.
But note the FUSE library (and its v3 branch) is currently unmaintained,
and older distributions do not ship it.

Some Linux distros have transitioned their packages away from fuse2.
Which results in less atention in these distros to fuse2, and therefore
a higher likelyhood that there would be distribution issues with the
corresponding packages.
There is also some likelihood the fuse2 packages may be eventually
droped by some of these.

So let's support either version, with a kconfig adapting to either API
and their quirks.

Note that both the fuse2 and fuse3 library code have quite a few
sideeffects on the process that uses it.

By now we continue defaulting to fuse2 as it is the most common.
But users can select to use the v3 if they have an issue w v2 or want
to start trying out using v3.

and a possible race fix, and 2 minor build fixes.

FUSE_INCLUDE_DIRS should be passed to the native_simulator build.
If there is several fuse libraries installed, we need to ensure the
bottom side of the driver is built with the correct include paths.
(These includes are irrelevant for the Zephyr side build)

Support having a list of include paths instead of single one.

Support having a list of libraries to link to instead of a single one.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Avoid a possible race between the FUSE thread and the Zephyr threads
during init.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Support using FUSE v3, instead of FUSE v2.

FUSE v3 has been out for a couple of years now, so most distributions
have it.
But note the FUSE library (and its v3 branch) is currently unmaintained,
and older distributions do not ship it.

Some Linux distros have transitioned their packages away from fuse2.
Which results in less atention in these distros to fuse2, and therefore
a higher likelyhood that there would be distribution issues with the
corresponding packages.
There is also some likelihood the fuse2 packages may be eventually
droped by some of these.

So let's support either version, with a kconfig adapting to either API
and their quirks.

Note that both the fuse2 and fuse3 library code have quite a few
sideeffects on the process that uses it.

By now we continue defaulting to fuse2 as it is the most common.
But users can select to use the v3 if they have an issue w v2 or want
to start trying out using v3.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Copy link
Contributor

@tpambor tpambor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be useful to add a sentence here to enable CONFIG_FUSE_LIBRARY_V3 if using fuse v3.

Note that this feature requires a 32-bit version of the FUSE library, with a
minimal version of 2.6, on the host system and ``pkg-config`` settings to
correctly pickup the FUSE install path and compiler flags.

How to select it, and what packages can be used.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
@zephyrbot zephyrbot added the area: native port Host native arch port (native_sim) label Sep 18, 2025
@sonarqubecloud
Copy link

@aescolar
Copy link
Member Author

I think it would be useful to add a sentence her

@tpambor mentioned now in the docs.

@cfriedt cfriedt merged commit 621255f into zephyrproject-rtos:main Sep 22, 2025
28 checks passed
@aescolar aescolar deleted the fuse3 branch September 23, 2025 08:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: File System area: native port Host native arch port (native_sim)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants