[Ovmsdev] Network Manager Ideas

Wed Dec 13 14:41:26 HKT 2017

Found a new issue with this today. I think it is caused by the SetAccess() in OvmsConfig::RegisterParam(). That is called during config loading from disk, and parameters are registered there (with default writable, but not readable). The SetAccess() was then modifying the existing parameters to not readable.

I added a check to OvmsConfig::mount() to only register parameters found on disk that were not already cached. That should work around it.

I’ve also noticed that the entire config system uses std::string (in particular during things like RegisterParam). Given what we now know about temporary std::string objects on the stack when character constants are passed to functions expecting std::string, that is not good. For example, I tried to add a RegisterInstance, and the 8 times I used this in SIMCOM modem initialisation would require 8x3x32 = 768 bytes of temporary stack space.

Can we comment-out/remove the #access parameter stuff for the moment, then I will try to change OvmsConfig to use char* for these constants?

Regards, Mark.

> On 13 Dec 2017, at 8:09 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> I think locations does it in the object initialiser, because there is no Init style initialiser for locations (as there is only one location object).
> 
> If we make these dynamic, we would need an ability to de-register a config parameter as well (presumably in the vehicle destructor). Steve recently made some changes/fixes to config to support ‘orphan’ config parameters (in /store, but not registered), and I think that might impact things here as well.
> 
> I think it is just simpler to make these parameter registrations permanent, and do them at boot time.
> 
> If we really want to make them dynamic, then we need to deal with the destructor Unregister case, as well as harden the protection around ‘#access’ style instances. Presumably Command registration has similar issues? How are RT specific commands handled?
> 
> Regards, Mark.
> 
>> On 13 Dec 2017, at 6:58 AM, Michael Balzer <dexter at expeedo.de> wrote:
>> 
>> It's actually done both ways in other modules up to now, i.e. the simcom module does it in the Init class, the locations does it in the constructor.
>> 
>> A disadvantage of doing it in the Init classes is, especially if we add instance defaults to the registration, all configs of all modules compiled in will
>> always be listed, regardless of the user actually needing or using them.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 12.12.2017 um 23:48 schrieb Michael Balzer:
>>> Another option would be to do the RegisterParam() call in the framework registration class, .i.e. OvmsVehicleRenaultTwizyInit. This would assure access rights
>>> are set on boot if the module is included, regardless of it being actually started.
>>> 
>>> That smells a bit like breaking the factory class pattern, but seems to be an alternative.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 12.12.2017 um 23:35 schrieb Michael Balzer:
>>>> 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 at 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 at 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 at lists.teslaclub.hk
>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at 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 at lists.teslaclub.hk
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at 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 at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 