Due to the nature of SCIONLab, we mainly expect modifications to the source upstream in these two forms:
- Change existing behavior.
- New features.
The first one, changing an existing piece of code, can be tackled quite well with the use of gopatch (link), which has been tested already by @juagargi and works quite well.
On the other hand, adding new features usually involves only modifying a small amount of existing code from upstream,
while much more often (in number of changes) adding code where there was none.
This has been done in the past in these instances:
- Adding a COLIBRI service.
- Adding a COLIBRI data-plane forwarding routine.
- Adding carbon impact as a new meta-information variable.
We do propose the use of Go plugins (link) in those entry points that we find out will be relevant for these types of endeavors. So far we have:
- Path Type: Allow forwarding of new path types
- Meta-information variables: allow the addition of new variables.
- (maybe) Useful for beacon selection and propagation (each AS could have their own function)
The use of plugins has to be first tested to ensure that:
- They correctly link to the existing upstream version. Do we need a versioning system, or is that taken care by
Go?
- Performance is not impacted, where performance is important. Namely, data-plane forwarding.
- Wrong configuration of the plugin preventing it to load properly will not affect the rest of the process. E.g. a wrong version of the plugin is loaded, whose symbols are incompatible with the main e.g. control service, forces an entry in the log as an error, but the control service resumes initializing and continues as usual.
To do:
Due to the nature of SCIONLab, we mainly expect modifications to the source upstream in these two forms:
The first one, changing an existing piece of code, can be tackled quite well with the use of
gopatch(link), which has been tested already by @juagargi and works quite well.On the other hand, adding new features usually involves only modifying a small amount of existing code from upstream,
while much more often (in number of changes) adding code where there was none.
This has been done in the past in these instances:
We do propose the use of Go plugins (link) in those entry points that we find out will be relevant for these types of endeavors. So far we have:
The use of plugins has to be first tested to ensure that:
Go?To do: