dasharo-binaries-paths-convention.md: Add #1170

philipanda · 2025-10-14T14:59:15Z

No description provided.

pietrushnic · 2025-10-14T15:20:36Z

docs/kb/dasharo-binaries-paths-convention.md

+
+The standardised path to a release directory is as follows:
+
+`/<vendor>/<model>/<framework>[_payload]/<version>/`


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

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.

That's why such a scheme should be implemented programmatically (being derived from variables) instead of being hardcoded. Of course, wherever it makes sense.

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

Ok, what would be your expectation?

I am not sure what you're asking for. Expectation from who, what?

My task is to clean up the directory structure because it was evolving for some time and got inconsistent. To do that I propose some structure that I believe would help with that.

From the directory structure I expect for it to be able to fit our needs for clearly separating all current and hopefully future Dasharo releases, and to be friendly for humans to navigate.

From you I expect you to give your opinions and whether the suggested solution is acceptable or not, what should be changed.

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

I wonder: why and what exactly is missing.

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.

The given framework/payload/platform/version should be unique (possible exception: initial commit for dasharo naming convention v2 #1154 (comment) ?). Matching to business names can be made elsewhere (e.g. in the release page, in the newsletter).

In a way, we already include this naming convention in this scheme, as we store different kind of releases in different places. Maybe this should be emphasized in the document - connect the editions with the storage.

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.

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.

pietrushnic · 2025-10-14T15:21:18Z

docs/kb/dasharo-binaries-paths-convention.md

+- `<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`


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

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

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.

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?

No, unless you can give me word it would not diverge.

docs/kb/dasharo-binaries-paths-convention.md

miczyg1 · 2025-10-16T11:09:00Z

docs/kb/dasharo-binaries-paths-convention.md

+where:
+- `<vendor>` - hardware vendor, like `novacustom`, `protectli`, `hardkernel`,
+  `pcngines`
+- `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4-plus`,


Suggested change

- `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4-plus`,

- `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4`,

https://github.com/Dasharo/docs/compare/fa1492a45bf2a0235e32c706966aac4c5ac8c78d..f4dbc9c13e7fb3a20e08ade820bf4060b47f5e82

miczyg1 · 2025-10-16T11:09:10Z

docs/kb/dasharo-binaries-paths-convention.md

+
+where:
+- `<vendor>` - hardware vendor, like `novacustom`, `protectli`, `hardkernel`,
+  `pcngines`


Suggested change

`pcngines`

`pcengines`

https://github.com/Dasharo/docs/compare/b801bdca20aa5f39737839f8680b3530f0ec6340..fa1492a45bf2a0235e32c706966aac4c5ac8c78d#diff-493f7626b31a79b1bd21a77d2782167f5856b920416de181ba6a8f321bf1b301L21-R21

Signed-off-by: Filip Gołaś <[email protected]>

mkopec · 2025-10-22T10:25:27Z

docs/kb/dasharo-binaries-paths-convention.md

+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


I woudn't say it makes little sense, when edk2 can be used as a complete end-to-end firmware solution

Good to know, @miczyg1 told me some time ago that it doesn't make sense, maybe I misunderstood it

@miczyg1 do you agree this description should be removed?

philipanda requested review from macpijan, miczyg1 and mkopec October 14, 2025 14:59

pietrushnic requested changes Oct 14, 2025

View reviewed changes

philipanda requested a review from BeataZdunczyk October 15, 2025 11:00

pietrushnic requested a review from DaniilKl October 15, 2025 11:39

miczyg1 reviewed Oct 16, 2025

View reviewed changes

philipanda force-pushed the dasharo-paths-convention branch from b801bdc to fa1492a Compare October 17, 2025 07:52

philipanda added 2 commits October 17, 2025 09:54

dasharo-binaries-paths-convention.md: Add

67aec67

Signed-off-by: Filip Gołaś <[email protected]>

dasharo-binaries-paths-convention.md: Add more path examples

f4dbc9c

Signed-off-by: Filip Gołaś <[email protected]>

philipanda force-pushed the dasharo-paths-convention branch from fa1492a to f4dbc9c Compare October 17, 2025 07:54

mkopec reviewed Oct 22, 2025

View reviewed changes


		The standardised path to a release directory is as follows:

		`/<vendor>/<model>/<framework>[_payload]/<version>/`

	- `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4-plus`,
	- `<model>` - Precise device model, like `v540tu`, `vp6670`, `odroid-h4`,

Uh oh!

dasharo-binaries-paths-convention.md: Add #1170

Are you sure you want to change the base?

dasharo-binaries-paths-convention.md: Add #1170

Uh oh!

Conversation

philipanda commented Oct 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

philipanda Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

philipanda Oct 15, 2025 •

edited

Loading