In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
Correct, N64 and PS1 era projects can essentially always be strictly tackled one function at a time. There are very minor things (like string literal sharing) where some earlier function can affect later function, but the workarounds are comparatively simple.
On the other hand, I have heard even old MSVC is a nightmare. Various things are affected by hash table ordering (so the names of variables matter in some situations), stuff like order of #includes mattering, etc.
Yuuuup exactly. I guess this is masked because old 90s games are often more culturally significant so people haven't found these problems yet but yes, these are serious challenges.
I just checked a few more. It looks it can sometimes tell the intent of a stack variable and give it a name. But anything working with data looks like above.
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
Correct way is to have everything as-if a source dependency, but a globally shared cache system that can automatically provide artifacts if that exact version of source has already been compiled.
Any system that can only consume manually built (and even in worst case, only tagged and globally pushed) dependencies is horrible for cross-module development, like large scale refactorings and the like.
This is exactly what I disagree with. It forces you to consider git your package boundary. You're now organising your source as if it was a package registry, when git can (and should) be orthogonal to that. Your problem with cross module development may even be because you're using git this way. If you want to do cross package development, having them in a monorepo and building two artifacts is the easy way. If that's not an option because the two packages need to be separate, you need a workflow that pulls the source together again.
To say nothing about hardcoded repo URLs (not resolvable identifiers), transient dependencies, URL schemes, and trying to pretend github is the only package source.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
reply