You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OSTree has long since adopted the use of fdt_file as the variable to track device tree names across deployments. In the Yocto-built Linux distribution that my company maintains however, we have been maintaining a patch for OSTree that adds support for fdtfile as that is what we use instead of fdt_file.
Ideally we'd like to drop this patch to have less maintenance burden. I was looking into why OSTree initially adopted the use of fdt_file, and as far as I can tell it was somehow determined to be the more prevalent variable name in U-Boot: ce2995e
Given this, I wanted to ask if it would be reasonable for OSTree to consider the use of fdtfile. Or if there was some other reason unknown to me that fdt_file is used. More realistically I imagine you'd want to have fdtfile exist in parallel alongside fdt_file. As changing fdt_file at this point risks breaking compatibility on other distros/setups.
If the idea to add support for fdtfile has no issues, then we would be happy to submit a PR for this as well.
The text was updated successfully, but these errors were encountered:
If the idea to add support for fdtfile has no issues, then we would be happy to submit a PR for this as well.
I'll be honest, my experience and knowledge is generally very datacenter/PC focused and I personally do not have extensive experience with devicetree specifically.
I can say first at a procedural level: Please please post any downstream patches that might exist upstream - at the very least in draft/RFC form - so they're more visible and discoverable and give a chance for upstream review. This is an aside but...and this one has long probably slipped out of most people's memory but I suspect e.g. the Debian openssl CVE would have more likely not happened had at least upstream had a chance to see the patch, but AFAIK it was never sent, just patched downstream.
Anyways, yes, at the very least let's get a PR up and discuss it there. Thanks!
OSTree has long since adopted the use of
fdt_file
as the variable to track device tree names across deployments. In the Yocto-built Linux distribution that my company maintains however, we have been maintaining a patch for OSTree that adds support forfdtfile
as that is what we use instead offdt_file
.Ideally we'd like to drop this patch to have less maintenance burden. I was looking into why OSTree initially adopted the use of
fdt_file
, and as far as I can tell it was somehow determined to be the more prevalent variable name in U-Boot: ce2995eThat said, U-Boot actually documents
fdtfile
as the standard variable name to use: https://source.denx.de/u-boot/u-boot/-/blob/master/doc/usage/environment.rstIt seems like this has been documented as such for quite a while: https://source.denx.de/u-boot/u-boot/-/commit/dc0b7b0e619e3f1413e626dde193fe21427ac831
Given this, I wanted to ask if it would be reasonable for OSTree to consider the use of
fdtfile
. Or if there was some other reason unknown to me thatfdt_file
is used. More realistically I imagine you'd want to havefdtfile
exist in parallel alongsidefdt_file
. As changingfdt_file
at this point risks breaking compatibility on other distros/setups.If the idea to add support for
fdtfile
has no issues, then we would be happy to submit a PR for this as well.The text was updated successfully, but these errors were encountered: