Hi Ryan, All, > On Sun, Nov 12, 2017 at 9:50 PM, Gordon Ross <[email protected] > <mailto:[email protected]>> wrote: > Sorry I didn't realize that change would cause API impact, or it might > have had more discussion. > Perhaps we should try to give people more warning about that kind of change. > > I was aware of no API impact when I made this change (I changed an internal > function). It was to make dladm behavior more intuitive based on an issue > filed by several SmartOS users.
I understand how you did and test your changes. > I also don't think Igor's issue is with my change per se, but with the fact > that libdladm was touched at all. I can't quite follow the scenario but it > looks like something to do with upgrading whole root zones? In any event, > from my understanding _any_ change to libdladm would cause the issue he is > describing. Let me provide additional info. this issue - where and how you did and check your changes - can show how are platforma different in some cases. for example: on DilOS, i have ipkg zone with OI where i have tested some OpenZFS changes by builds. i have ported changes from SmartOS for zones/networking with LX zones ports and right now i’m using scheme for zones with exclusive ip-type: up vnic with zone and remove it with power off zone. it’s mean - vnic is up in zlobal zone and provided to zone whwere it can be configured with IP. with new changes in persisten identification scheme - we can see vnic in zone as temporary and statis IP coupld not be assigned to it. and, as result, i can’t use old ipkg zone with OI - i have to upgrade zone with networking tools to be in sync with global zone. I’m using DilOS platform for my builds/tests and can run different zones - ipkg with OI, smartos with pkgsrc, dpkg with dilos, lx zones. But, changes like this one, impact it. It is example can show: how we are depend on API/ABI changes. it can impact to some others who are working on automatization of tools for setup of server by web/another applications and we need the way : how to provide info about major/primary changes to others, not to me only. I can see interest solution with GNU LD where some library can do map of 1 funtion in ABI to different realization with dependency to library version. I think, thay had similar issue where they need provide support to different platform wth different library versions and for transitions of applications from one version to another. By this eaxmple we can see issue: we need try to think/organaze release process for similar changes where we do updates in interfaces/functionality. i’d like propose to use scheme: we can create git tag with some stamp/version and put some info to illumos wiri where we can provide info about: what changes in interfaces was updated and should be using from this version/tag. it can help to others to be in sync with illumos versions. i’m not proposing to do weekly/beweekly releases, but to do some tags/markers for important updates. sorry for my English :) I try to explain situation how i can :) best regards, -Igor > > -rpz > illumos-developer | Archives > <https://illumos.topicbox.com/groups/developer/discussions/T2da3f608fca46f0d-M7dc176e8bcd77e0a7ce6d4b9> > | Powered by Topicbox <https://topicbox.com/> ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tc85856698599769e-M1ef8435cd2155694c39dbbab Powered by Topicbox: https://topicbox.com
