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

[FR] Embed the enabled plain text #defines from configuration files #7650

Closed
dot-bob opened this issue Sep 12, 2017 · 7 comments
Closed

[FR] Embed the enabled plain text #defines from configuration files #7650

dot-bob opened this issue Sep 12, 2017 · 7 comments
Labels
C: Configuration T: Feature Request Features requested by users.

Comments

@dot-bob
Copy link
Contributor

dot-bob commented Sep 12, 2017

This is more of a new feature request / discussion. I wonder if we should craft a way to embed the text of all the enabled #defines of the configuration.h and configuration_adv.h files in the firmware.
This would be similar to how you can retrieve the configuration of a compiled Linux kernel.

Perhaps we could craft it in a way that it would be beneficial for manufactures to leave it in or to make some essential functions rely on part of it. For instance make the string table depend on portions of it. This would help with the hit to the added space and make it beneficial to manufactures to leave it in. Or we can go as far as if it isn't left in or at least partially then the firmware may miss functionality and or advanced features.

This might help combat the manufactures that don't supply the configuration or firmware. But at the very least help you determine what settings and features are compiled in.

-Rob

@oysteinkrog
Copy link
Contributor

This is a good idea, but I think many of the 8-bit boards have very limited storage space, so that may be a challenge/constraint.

@fiveangle
Copy link
Contributor

fiveangle commented Sep 20, 2017

Agree, cool idea: kind of like how they embed cue sheets / song names for full-length MP3/FLAC files in order to fully restore to original configuration.

The only way I could envision this working is if we maintained a bitmap tied to each release so it wouldn't add hardly any resource usage, but even then once mfrs get ahold of it, that would go out the window and would be useless.

The full text strings of the compile-time config could probably be embedded for 256k boards without much issue, but since on 128k boards every bit is accounted for, even 2k for a "mandatory" feature that added no working value would be a hard sell.

@thinkyhead thinkyhead added the T: Design Concept Technical ideas about ways and methods. label Feb 9, 2018
@thinkyhead
Copy link
Member

It's a tall order. One more thing that would need to be maintained in perfect synchronization with all settings, and which would need to have a structure that can be extracted. Even as configuration options evolve and change across versions… Unless some homebound person is passionate about this, it's unlikely to be maintained very well.

@boelle
Copy link
Contributor

boelle commented Jun 22, 2019

should this not have the feature request label?

@boelle boelle added T: Feature Request Features requested by users. and removed T: Design Concept Technical ideas about ways and methods. labels Jul 21, 2019
@sjasonsmith
Copy link
Contributor

@rhapsodyv has posted one possible solution to this: #20081

@thisiskeithb
Copy link
Member

Added in #21321

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Mar 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C: Configuration T: Feature Request Features requested by users.
Projects
None yet
Development

No branches or pull requests

7 participants