your proposal sounds fine to me.
eric
On Tue, Jan 30, 2007 at 12:29:13PM +0800, Cathy Zhou wrote:
> 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
>
