I've initiated this discussion to explore incorporating driver-specific types within the library, with a particular interest in Netkit. However, the approach could extend to others such as Vxlan and Bond. Currently, driver-specific data is managed through LinkInfo.Data and/or LinkInfo.SlaveData as byte slices. To define concrete types for these drivers, we need a new mechanism. I propose several approaches and have prepared POC branches to illustrate these ideas, though I'm open to further suggestions for the most effective implementation. Your input would be invaluable to refine these proposals.
-
Interface Integration within LinkInfo: Adding a new interface within LinkInfo to handle driver types based on the Kind dynamically. This approach maintains backward compatibility. Example POC.
-
Revision of Data Fields as Interfaces: Transforming LinkInfo.Data and SlaveData into interfaces. This method would necessitate a major version update due to its backward-incompatible nature. Example POC.
-
Driver Types in LinkAttributes: Embedding driver types directly within LinkAttributes. This method could provide operational benefits, such as compatibility checks. For example, Netkit does not support setting ethernet address, in this way, we could check this condition Example POC.
I've initiated this discussion to explore incorporating driver-specific types within the library, with a particular interest in
Netkit. However, the approach could extend to others such asVxlanandBond. Currently, driver-specific data is managed throughLinkInfo.Dataand/orLinkInfo.SlaveDataas byte slices. To define concrete types for these drivers, we need a new mechanism. I propose several approaches and have prepared POC branches to illustrate these ideas, though I'm open to further suggestions for the most effective implementation. Your input would be invaluable to refine these proposals.Interface Integration within LinkInfo: Adding a new interface within
LinkInfoto handle driver types based on the Kind dynamically. This approach maintains backward compatibility. Example POC.Revision of Data Fields as Interfaces: Transforming
LinkInfo.DataandSlaveDatainto interfaces. This method would necessitate a major version update due to its backward-incompatible nature. Example POC.Driver Types in
LinkAttributes: Embedding driver types directly withinLinkAttributes. This method could provide operational benefits, such as compatibility checks. For example,Netkitdoes not support setting ethernet address, in this way, we could check this condition Example POC.