Nicolas, Eric and the team,
Please let me know if you have any objection, or I'll start to working on
the first phase of the restructure: simply merge these libraries into one
libdladm library and change the function names to be prefixed with "dladm_"
Thanks
- Cathy
>>> 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.
>>
> Right. That's the plan.
>
>> 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?
>>
> No. It will not be a larger API and we are planning to keep the current
> layers of libraries even we are merging them into one library. We choose
> to prefix all functions with "dladm" because they are all part of
> datalink (dl) management API, while I don't think we have a good
> justification for the current laadm_xxx() names as there is no utility
> named laadm. Note that libdladm is different from libc in this respect,
> as its components (aggr, vlan, iptun, wlan ...) are tied more closely -
> for example, when each specific component execute certain operation, it
> needs to call back to the dladm common routines to manipulate the link
> ids, and to persist the configuration. As an example, a laadm_create()
> will be like:
>
> laadm_create()
> {
> dladm_create_linkid(aggr, DLADM_CLASS_AGGR, &aggrid);
> dladm_create_conf();
> dladm_set_conf_field();
> dladm_write_conf();
> i_laadm_ioctl(DLDIOC_CREATE_AGGR);
> }
>
> In addition, the function will return the error code from a unique name
> space.
>
>>
>> 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.
>>
> OK.
>
> Thanks
> - Cathy
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org
