You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Study the questions above.
Create a plugin system for e.g. the border router data-plane.
Create gopatch patches for this plugin system.
Contact the SCION Association to study the possibility of using our plugin system in general.
Merge to upstream whenever possible, and remove the corresponding gopatch.
Simultaneously proceed with the rest of the plugin systems (e.g. meta-information variables).
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: