sys: remove config module

[kaspar030]

IMHO this module is unmaintained and unused... Do we still need it?

[OlegHahm]

👍 for removing this, but we definitely need a replacement.

[jnohlgard]

I suggest a vfs or nvram based replacement. that should go in a separate PR
though.

Den 18 aug. 2016 10:46 AM skrev "Oleg Hahm" notifications@github.com:

👍 for removing this, but we definitely need a replacement.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5756 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATYQkrvOuFu4BRywS6gixIHrIENI4Rdks5qhBvJgaJpZM4Jm18w
.

[OlegHahm]

Sounds a bit like overkill to me. Think of MSP430 and its INFOMEM (a small flash section, intended to store persistent device specific information).

[kYc0o]

So should we close this #162 issue?

[miri64]

Sounds a bit like overkill to me. Think of MSP430 and its INFOMEM (a small flash section, intended to store persistent device specific information).

Why would it be overkill to implement a very simple read-only vfs backend for this and make it something comparible to /proc or /sys on Linux? I think this only would provide more consistency to more powerful platforms if they provide something like this as well.

[OlegHahm]

A whole filesystem to store some bytes in a persistent way sounds certainly like overkill to me and I don't see any benefit.

[jnohlgard]

@OlegHahm I didn't mean a whole file system for a config store. What I meant is that the implementation should be either an NVRAM device, or a file-like persistent memory using the VFS API. Using familiar APIs such as vfs_read/write would just make it easier to use from an application developer point of view.
The "file system" driver does not need to support multiple files, just a single file which is the interface to the backing memory. Similar to what a /dev/sdx device does in Linux.

[LudwigKnuepfer]

I guess it is worthwhile to move the discussion about what to do as a replacement to a dedicated issue.

[jnohlgard]

I agree, I think since this PR has been open for more than a week, I don't think anyone will mind that we remove this module until a replacement is ready.

[kaspar030]

• fixed last build errors, squashed

[LudwigKnuepfer]

ACK