Le 29/03/26 à 18:15, Richard Purdie a écrit :
For context, these previous versions were in 2023. I think the general
concern is we already have a lot of rootfs size related variables and
adding more of them complicates the user interface. It isn't clear
which ones "win" when multiple conflicting settings are made.
In this case the max size "wins" above any of the others.
IMHO this makes sense because it's more specific and related to the real
filesystem size.
But indeed if you want to change the design behind, I'm open to it.
It does
appear that it isn't just a max size but a fixed size in that it will
pad the filesystems to this size? That makes the name a bit
confusing/misleading and was one of the concerns last time.
In fact I realize that I've not read your previous answer last time, too
focus on the CI error. Sorry, my mistake. That's why I've not taken this
into account for my recent changes.
Yes, this variable is doing both (fixed + max size of the filesystem),
due to how filesystem tools are working. Maybe by having a more
"intrusive" change, we can improve it.
What I can suggest is:
* IMAGE_ROOTFS_MAXSIZE would be used against filesystem sizes, and not
against precomputed rootfs sizes as done today, it's likely not really
relevant to keep current behavior as it. I don't know if we would be
able to customize the value per filesystem type as done in my proposal
or if a global setting is good enough.
* if IMAGE_ROOTFS_EXTRA_SPACE is set to 0 and IMAGE_OVERHEAD_FACTOR set
to 1.0, don't provide size parameter to mkfs to create a dynamic and
minimal filesystem, to avoid the need to always provide manually extra
margin just for filesystem overhead
* Then introduce a new variable like IMAGE_ROOTFS_FIXED_SIZE which can
be provided (if set) to mkfs tool to have a fixed partition size
whatever are the other settings related to rootfs size. If unset (by
default), previous logic can be used instead.
I'm not an expert of all filesystems so maybe this suggestion can
introduce problems. I don't see potential regressions for current users
as well.
What do you think? Another ideas?
Thank you for your feedback.
Regards,
--
Charles-Antoine Couret
Embedded Software Developer
+32 488 27 56 40
Website <https://mind.be> • LinkedIn
<https://www.linkedin.com/company/mind_essensium/> • Newsletter
<http://eepurl.com/h-gy7v>
<https://mind.be> logo
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#234153):
https://lists.openembedded.org/g/openembedded-core/message/234153
Mute This Topic: https://lists.openembedded.org/mt/118563509/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
