Hi,

As you might be aware, we had some discussions around the above 3 libraries 
before. In particular, there are two issues being discussed:

a) the error code namespace

b) the linkprop support

In both area, 3 libraries have similar processing logic and could share most 
amount of code, and we believe they have other processing (such link 
configuration persistence) in common.

For now, I've merged the error code namespace and the linkprop support logic 
into libdladm so that other libraries can use them directly. Specifically 
for the linkprop support, currently I have each other libraries to register 
a linkprop table to libdladm, and libdladm can process based on the 
information stored in that table.

Kacheong also suggested that we could merge these 3 libraries together[1], 
so that we could skip the registration step.

The stack instance project is going into Nevada soon. As they will add a 
"zone" linkprop, I'd like to know which approach is the best for them to 
take: they can either add the "zone" linkprop support in libdladm and share 
no code with libwladm, or they can use the registration approach as 
prototyped in my workspace, or they can merge those 3 libraries together so 
that sharing common routines won't be a problem.

The last 2 options need PSARC process so that it might not be appropriate as 
their integration date is very close.

Please advise.

Thanks
- Cathy

[1] even those libraries are merged together, I would think we can still 
split the library into 3 components to make the code clearer, but we don't 
need to consider the library dependencies.

Reply via email to