Revert "doc: storage: retention: move retention docs under storage"

[nordicjm]

This reverts commit 8c6c350.

This change was not approved by the maintainer (i.e. me) and wrongly moved retention (which is for RAM or RAM-like register peripherals) under storage, which is meant for things like flash

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kartben]

Storage is for ... storage (as in, storing information)? There is no reason that high-level storage service should have anything to do with Flash/non-volatile vs. RAM, don't you think?

FWIW this change is part of an ongoing overhaul of the "services" documentation to help with discoverabilty of all the many services and subsystems we have, and with all due respect I am pretty sure having "Retention" alongside "all things storing information" is an improvement over having it buried alongside three dozen other random services.

Related question: what do you think would be a better category for Retention if Storage is not a good fit? Thanks!

[nashif]

how about calling the category something else like "Persistent Storage & Data Management" or "State Persistence & Storage" to make it better fit?

[nordicjm]

Storage is for ... storage (as in, storing information)? There is no reason that high-level storage service should have anything to do with Flash/non-volatile vs. RAM, don't you think?

Storage is used commonly with things you store, persistently. A RAMDISK might have a filesystem, but people don't refer to them as storage, if they power off (or reboot depending upon devices) then the contents are lost. Likewise with tmpfs on linux, people do not refer to that as storage

FWIW this change is part of an ongoing overhaul of the "services" documentation to help with discoverabilty of all the many services and subsystems we have, and with all due respect I am pretty sure having "Retention" alongside "all things storing information" is an improvement over having it buried alongside three dozen other random services.

Not when it's not representative of the category. I wouldn't expect to go to the logging page to find the ethernet documentation

Related question: what do you think would be a better category for Retention if Storage is not a good fit? Thanks!

Volatile configuration, that's what I would sum it up as but that's not really the name of a category but might be able to get one from that

[nordicjm]

how about calling the category something else like "Persistent Storage & Data Management" or "State Persistence & Storage" to make it better fit?

Storage to me already fits the description fine, from https://dictionary.cambridge.org/dictionary/english/storage

the act of keeping things somewhere so that they can be used later, especially goods or energy supplies

which is exactly what you would when storing things on NVM, you want them to use later, it's not much use if things you store vanish

[kartben]

Storage is for ... storage (as in, storing information)? There is no reason that high-level storage service should have anything to do with Flash/non-volatile vs. RAM, don't you think?

Storage is used commonly with things you store, persistently. A RAMDISK might have a filesystem, but people don't refer to them as storage, if they power off (or reboot depending upon devices) then the contents are lost. Likewise with tmpfs on linux, people do not refer to that as storage

Right, I see what you mean now, thanks. For what it's worth there definitely seems to be (lots of?) "people" conflating all these things under the general "Storage" umbrella though:

• tmpfs is definitely under "Storage Services" in the Linux kernel docs https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html ; so are sections about e.g. RAMfs https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html
• https://en.wikipedia.org/wiki/Tmpfs ("tmpfs (short for temporary file system) is a temporary file storage paradigm [...]")
• RAM seems to be commonly accepted as "volatile storage", in contrast to "non-volatile" (ROM, optical, ...) - https://en.wikipedia.org/wiki/Template:Memory_types / https://en.wikipedia.org/wiki/Computer_memory
• "temporary storage" seems pretty widely accepted term too, e.g. in https://en.wikipedia.org/wiki/RAM_drive, https://en.wikipedia.org/wiki/Volatile_memory etc.

FWIW this change is part of an ongoing overhaul of the "services" documentation to help with discoverabilty of all the many services and subsystems we have, and with all due respect I am pretty sure having "Retention" alongside "all things storing information" is an improvement over having it buried alongside three dozen other random services.

Not when it's not representative of the category. I wouldn't expect to go to the logging page to find the ethernet documentation

Ok, but I don't think I have suggested moving ethernet to the logging page?

Related question: what do you think would be a better category for Retention if Storage is not a good fit? Thanks!

Volatile configuration, that's what I would sum it up as but that's not really the name of a category but might be able to get one from that

Thanks, that helps. Will be maybe grouping all things settings/configuration, then...
Or it might also be that the categories end up being more like "tags", with things potentially belonging to more than one (e.g. Retention has to do with Storage and Configuration)

Edit: sort of answering myself, Settings is already under Storage currently, and has Retention as one of the available backends.

[nordicjm]

Thanks, that helps. Will be maybe grouping all things settings/configuration, then...
Or it might also be that the categories end up being more like "tags", with things potentially belonging to more than one (e.g. Retention has to do with Storage and Configuration)

I think that's probably a good idea to have a dedicated page for "settings" and settings-like systems

[kartben]

@nordicjm the Services doc rework PR I was referring to is up for review #100126