... | ... | @@ -794,3 +794,8 @@ func (r *RestAPI) DeleteSession(ctx context.Context, params users.DeleteSessionP |
|
|
...
|
|
|
}
|
|
|
```
|
|
|
|
|
|
# Comments
|
|
|
|
|
|
* In Kea, loading a hook library of a different version can cause a memory corruption which can lead to the termination of the core server. The more functions you call from the hook library, the greater the chance of the corruption to happen. While this is more acceptable in a process like Kea which can be restarted with a fallback configuration, you probably want Stork processes to be more resilient to this type of situations so that an error message survives to the GUI. The version check helps in preventing a crash. However, the version check itself involves Open()-ing the library and calling a function per this design. Since the version is known to return a string (or two per the design, I can't figure out why) this could be reduced to a simple variable which can be Lookup()-ed, which is arguably more safe, and also consistent with the core representation of a version which is also a simple string. I would advise testing and observing how the go plugin modules behaves in this case. Checking the version before calling Load() helps as well. Kea issue 2428 documents how you can get a reliable segfault by loading another version's hook library. It seems it is caused by dlclose() so the lack of it here may also help and may have been by design. (Andrei)
|
|
|
* There is some focus on CLI flags. I imagine them as being the words prefixed with dashes passed to an executable like `--help` or `--version`. If that's not accurate, ignore this point. Custom CLI flags + dynamic reconfiguration brings up some questions. If the custom CLI flag is new, how does the user have the ability to use it, since the flags were already passed? If the custom CLI flag is old, as in already in the set of CLI flags, either provided by the core daemon or provided by another hook library, is it accepted without question and with the previously passed value? (Andrei) |