Hi Nicolas, I talked about this restructure with Meem today, and he feels strongly (which I agree) that after the restructure, the function names should be refactored to match the merged library names.
For example, currently the liblaadm has functions named as laadm_xxx() (for example, laadm_create()), and you can see from my webrev that those functions will return DLADM_STATUS_XXX because I merged the error codes to share a single name space. The more nature function naming after the merging should be change those names into dladm_aggr_xxx(). We understand this involves a lot of changes, not complicated but tedious, so we'd like to pursue it in a phase by phase approach. The first phase will be just merge the libraries into one and change the function names, and also merge the error code namespace. I will not keep the old libraries (libwladm, liblaadm) and their exported interfaces, so that I will need to file a fasttrack and run it through the PSARC. We will do this asap if you agree that merging these libraries is the way to go. We strongly think this is the right way to go, especially after all the libraries will soon share the same configuration persistence. Please let me know what do you think. Eric, I'd like to know your suggestion of the function names of wladm_xxx() after the merging. I'd like to keep the name to match to the subcommand name, so it would be dladm_wifi_xxx() but Meem said you once mentioned these wxadm_xxx() functions will be used by other wireless technologies so maybe dladm_wl_xxx() is more correct. Thanks - Cathy >> To: >> clearview-discuss <clearview-discuss at opensolaris.org>, >> Sowmini.Varadhan at Sun.COM, Nicolas Droux <Nicolas.Droux at Sun.COM> >> CC: >> >> >> Hi, >> >> As you might know, I am working on the restructure of libdladm, >> liblaadm, and libwladm. Basically to let them share as much code as >> possible, and try to merge them into a single library. At the same >> time, will still keep them as independent components. >> >> I am currently focusing on sharing the code of the error processing >> and linkprop processing. For error processing, I simply let them share >> the same error code namespace; and for linkprop processing, each >> component should register a linkprop processing table, which include >> all specific routines to handle specific linkprop. (see >> wladm_register() function) >> >> Below is the webrev. >> http://jurassic.sfbay/net/aquila.prc/export/home/cathy/snv-dev/webrev/index.html >> >> >> >> Note that in order for you to read webrev, I haven't merged the >> libraries yet. But I am planning to do so. That will involve >> restructuring functions and files. >> >> I am not expecting a review yet, please have a look and see whether >> this approach is okay. >> >> There might be other things can be done. Specifically, every component >> should be able to register a walk() callback and a up() callback, in >> order for the libdladm to walk through all the links of one specific >> type and also recreate links when the system boots up. But I am >> hesitated to do so because: >> >> a. after vanity naming, walking links will be significantly changed: >> walking specific type of links will be going through the <link name, >> linkid> table in the linkid management component instead of each >> component sending an ioctl to the kernel to get the lists of links. >> >> b. Even after vanity naming, I don't think we can merge up_aggr, >> up_iptun, up_vlan into a single up_link operation, because these links >> needs to be recreated in a specific order (aggr->vlan), and even in >> different smf service (aggr and vlan in network/physical service and >> iptun in network/iptun service). Therefore, dladm cannot recreate all >> links blindly, so that having each component register a up() callback >> may not make sense. >> >> What's your suggestion? I don't think I can integrate without >> finalizing the dladm_register_t structure. But at the same time, other >> projects has dependencies on the linkprop processing restructure, and >> the earlier we can share the solution, the easier for all the projects >> the sync up. >> >> Thanks >> - Cathy >> >> _________________________________ >> clearview-discuss mailing list >> clearview-discuss at opensolaris.org >
