|
|
1 개월 전 | |
|---|---|---|
| .. | ||
| eeprom | 0a873001c4 Merge remote-tracking branch 'origin/develop' into xap | 1 개월 전 |
| nvm_dynamic_keymap.h | 2b00b846dc Non-volatile memory data repository pattern (#24356) | 1 년 전 |
| nvm_eeconfig.h | 0d6dbe4a5f Merge remote-tracking branch 'upstream/develop' into xap | 1 년 전 |
| nvm_via.h | 2b00b846dc Non-volatile memory data repository pattern (#24356) | 1 년 전 |
| readme.md | 4f7a7873c8 [CI] Format code according to conventions (#26000) | 5 달 전 |
| rules.mk | 2b00b846dc Non-volatile memory data repository pattern (#24356) | 1 년 전 |
This area is intentionally structured in the following way:
╰- quantum
╰- nvm
├- readme.md
├- rules.mk
|
├- nvm_eeconfig.h
├- nvm_<<system>>.h
|
├- eeprom
| ├- nvm_eeconfig.c
| ├- nvm_<<system>>.c
| ╰- ...
|
├- <<another provider>>
| ├- nvm_eeconfig.c
| ├- nvm_<<system>>.c
| ╰- ...
╰- ...
At the base nvm level, for every QMK core system which requires persistence there must be a corresponding nvm_<<system>>.h header file. This provides the data repository API to the "owner" system, and allows the underlying data persistence mechanism to be abstracted away from upper code. Any conversion to/from a .raw field should occur inside the nvm_<<system>>.c layer, with the API using values, such as structs or unions exposed to the rest of QMK.
Each nvm "provider" is a corresponding child directory consisting of its name, such as eeprom, and corresponding nvm_<<system>>.c implementation files which provide the concrete implementation of the upper nvm_<<system>>.h.
New systems requiring persistence can add the corresponding nvm_<<system>>.h file, and in most circumstances must also implement equivalent nvm_<<system>>.c files for every nvm provider. If persistence is not possible for that system, a nvm_<<system>>.c file with simple stubs which ignore writes and provide sane defaults must be used instead.