Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fdtfile versus fdt_file #3235

Open
jsrc27 opened this issue May 1, 2024 · 1 comment
Open

fdtfile versus fdt_file #3235

jsrc27 opened this issue May 1, 2024 · 1 comment

Comments

@jsrc27
Copy link

jsrc27 commented May 1, 2024

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

That 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.rst

It 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 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.

@cgwalters
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants