It's necessary if we want to be able to see configs of not yet loaded modules, i.e. vehicles. Without the persistance the configs are not readable before the module is actually loaded by the user -- so a module configuration can also not be checked without loading the module. That was my reason to change this: without persistance, I cannot see my Twizy configuration after boot before issueing "vehicle module RT". If a part of my config needs to be changed before starting the module, I cannot see what I've set before. You're right in the special meaning of instance names prefixed with "#" -- these should not be allowed for this serialization form. I chose "#" as that's a typical comment line character, and I thought names like this will normally not be used. I'll add a check to prevent using instance names colliding with that pattern, if you agree on the basic solution. Regards, Michael Am 12.12.2017 um 23:19 schrieb Mark Webb-Johnson:
It is the second one I am not sure is necessary.
If access is controlled by the Register, why persist at all? What would happen if the permissions in Register were changed? What would happen if an instance "#access" was set?
Regards, Mark
On 13 Dec 2017, at 5:54 AM, Michael Balzer <dexter@expeedo.de> wrote:
I've pushed two commits regarding this, the first only fixed the primary problem of not setting the access rights again on RegisterParam() after loading the config cache.
The second one adds storage persistance, as I think it's OK to persist this info. The RegisterParam() call will always set the current access rights as programmed, this is only meant to restore the latest access rights of parameters registered by loadable modules like vehicles.
So I think this should be OK?
Regards, Michael
Am 12.12.2017 um 22:45 schrieb Mark Webb-Johnson: Michael,
I don't think this is correct/necessary.
The access rights are provided in the Register command, when the parameter is registered. This is done each and every time. We don't need to persist this to /store file system.
There was an issue with load order - where parameters could be loaded before the Register function call. Perhaps that is what is causing the bug you are seeing? The code was fixed to work around this, but perhaps it is not setting the access rights correctly in that case?
Regards, Mark
On 13 Dec 2017, at 3:32 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 12.12.2017 um 20:12 schrieb Michael Balzer: Btw: I've always registered my config "x.rt" as readable, but "config list x.rt" will no longer show any values. I'm pretty sure it did before. Found & fixed, the access rights wouldn't be restored on loading the config.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26