On Fri, Jan 26, 2007 at 12:42:32AM +0800, Cathy Zhou wrote: > 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(). > what's the reason for changing the function names?
to me, the merged libdladm would be similar to libc - it consists of multiple distinct APIs that could potentially evolve or be used separately. e.g. to use wireless APIs, an app would just include libwladm.h (to be renamed wladm.h?), which in turn would include libdladm.h which contains the common error codes. by changing the interfaces to dladm_<type>_xxx(), they would appear to be part of a larger API rather than distinct pieces. is this the intention? of course, changing names does not preclude the above from being used separately. I just thought it would be clearer if this weren't done. to me, the prefix dladm_ seems to imply something common to all link types, and so should be reserved for such interfaces. > 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. > no, WL_ was taken by wifi_ioctl.h. that's why wladm_ was chosen. I suggest you use dladm_wlan_ if you were to go ahead with the rename. eric > 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 > > >
