dasharo-binaries-paths-convention.md: Add #1170
Conversation
|
|
||
| The standardised path to a release directory is as follows: | ||
|
|
||
| `/<vendor>/<model>/<framework>[_payload]/<version>/` |
There was a problem hiding this comment.
this have to be directly connected with naming convention or even be part of naming convention as part of subsection, otherwise it would be quickly out of sync
There was a problem hiding this comment.
It would be better if it never went out of sync by being as universal as possible. That's why I've been asking about creating more variants of Dasharo with the same framework+payload. A lot of projects (I've counted 10 repositories) depend on the directory structure and updating it will soon, and would in the future, be costly.
There was a problem hiding this comment.
That's why such a scheme should be implemented programmatically (being derived from variables) instead of being hardcoded. Of course, wherever it makes sense.
There was a problem hiding this comment.
At the same time it should be compatile with humans too. People use dl.3mdeb.com or dlui.3mdeb.com. It should be easy to manually find what youre looking for there or just explore what's available while understanding what you're looking on
There was a problem hiding this comment.
Ok, what would be your expectation?
There was a problem hiding this comment.
I am sure we will be changing these names. Putting them in the paths will make us changing the paths more often over and over again.
Yes. Exceptions appear from time to time. We are also not very strict about following our own naming rules when it comes to paths and files. E.g. MTL iGPU and dGPU was one of that cases where out of a sudden binaries changed their paths because nobody could distinguish dPGU from iGPU, despite it is unique (TNx is dGPU, TU is iGPU) - I was very dissatisfied with that. We often create mess ourselves when it comes to paths.
There was a problem hiding this comment.
E.g. MTL iGPU and dGPU was one of that cases where out of a sudden binaries changed their paths because nobody could distinguish dPGU from iGPU, despite it is unique (TNx is dGPU, TU is iGPU)
To help with that issue I'm suggesting here to separate every unique model into its own directory. The binaries can, and should, be the same for compatible boards, but separating the models explicitly in the directory should help with similar scenarios in the future. It should be trivial to modify all the uploading scripts to upload a single binary into multiple directories if it works for more than one device model.
There was a problem hiding this comment.
It should be trivial to modify all the uploading scripts to upload a single binary into multiple directories if it works for more than one device model.
Note that we rapidly increase the amount of artifacts. Capsules, raw binaries (those x2 because of dev_signed) and fwupd cabinets, also Boot Guard... it will mean that we need extra 100MB+ space per model for identical binaries if one binary supports multiple models. It will quickly get out of hand and deplete our storage pool. Links or redirects would be much better.
There was a problem hiding this comment.
All our Dasharo releases as of today take ~ 20 GB
I'm not sure how dl.3mdeb.com and dlui.3mdeb.com are implemented, but if making symlinks would possible, then it sure would be good to save a couple gigabytes, why not.
There was a problem hiding this comment.
I think we should not optimize for size in the naming convention. If this becomes a problem, it can be resolved via other tools on higher layers.
| - `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4-plus`, `apu-4` | ||
| - `<framework>` - firmware framework, like `coreboot`, `slimbootloader`, `heads` | ||
| - `[_payload]` - optional, firmware payload, like `_uefi`, `_heads`, `_seabios` | ||
| - `<version>` - Dasharo version, like `v0.9.0`, `v1.7.2-rc1` |
There was a problem hiding this comment.
if connected with convention documentation this would be redundant, also we should link to versioning scheme documentation and make sure it respect rules we currently apply
There was a problem hiding this comment.
Linked the versioning scheme. I think ideally it shouldn't be connected with naming convention, it should be more generic and allow for the naming convention to change without affecting the directory structure
There was a problem hiding this comment.
Such a connection by linking is too weak; it would be better if this document were placed inside the convention documentation. Maybe we need @macpijan here to support or discourage such thinking.
There was a problem hiding this comment.
I'm interpreting the other discussions in this PR to mean that we want to make the directory structure independent of the naming convention.
Do you still hold your claim that the naming convention and directory structure documents should be merged?
There was a problem hiding this comment.
No, unless you can give me word it would not diverge.
There was a problem hiding this comment.
I can give you a word that it will diverge, so I think there is no point in trying to make them connected more than it is natural due to the binaries contents. A binary does not need to be released, but should still have a place in the structure.
There was a problem hiding this comment.
I'm interpreting the other discussions in this PR to mean that we want to make the directory structure independent of the naming convention.
Yes, I'm more in favor of having them independent and focus here in paths on the binary content, not how we sell them.
philipanda
force-pushed
the
dasharo-paths-convention
branch
2 times, most recently
from
fa1492a to
f4dbc9c
Compare
| always be there, even if a platform has only support for a single | ||
| framework/payload combination to reduce the ambiguity. | ||
|
|
||
| It's argueable that a firmware framework without a payload makes little sense |
There was a problem hiding this comment.
I woudn't say it makes little sense, when edk2 can be used as a complete end-to-end firmware solution
There was a problem hiding this comment.
Good to know, @miczyg1 told me some time ago that it doesn't make sense, maybe I misunderstood it
There was a problem hiding this comment.
@miczyg1 do you agree this description should be removed?
There was a problem hiding this comment.
@philipanda we know this makes sense with our EDK2 implementation on the Odroid M2: https://blog.3mdeb.com/2025/2025-07-17-edk2-on-odroid-m2/
Let's address the review in this thread.
There was a problem hiding this comment.
There was a problem hiding this comment.
@mkopec yes, but EDK2 does not have any concept of payload when building UEFI-compliant firmware... So EDK2 is not applicable here. The firmware is not called <framework>+<payload> but just UEFI or EDK2 then...
There was a problem hiding this comment.
#1154 is a better place to discuss it.
The option to use a more generic <variant> field here is still possible. I don't want for the directory structure to break because of some little changes to the naming convention, so I'd opt for using <variant> if there is no agreement
There was a problem hiding this comment.
Proposed scheme already has framework and optional paylaod. So EDK2 without payload still fits into this scheme.
philipanda
force-pushed
the
dasharo-paths-convention
branch
from
f4dbc9c to
a24da89
Compare
Signed-off-by: Filip Gołaś <[email protected]>
philipanda
force-pushed
the
dasharo-paths-convention
branch
from
a24da89 to
110391b
Compare
Signed-off-by: Filip Gołaś <[email protected]>
philipanda
force-pushed
the
dasharo-paths-convention
branch
from
110391b to
e5115b9
Compare
No description provided.