Eric Cheng wrote: > On Tue, Dec 12, 2006 at 04:12:29PM +0800, Cathy Zhou wrote: >>> I agree that the compare, get, ... semantics are generic, >>> but the actual comparison, checking, ... is type specific. >>> So if you want to make the logic general, I guess you need >>> to provide the mechanism for adding new types, without the >>> need to change the generic code. >>> >> The comparison will be most based on "char *", and the real value will be >> change from uint_t to void *. Note that what I inclined to do now is to >> make the current do_set_prop() function to be a libdladm() API which can be >> called by each library. Using this model, different library can define its >> own table of property table, and each property can define its own >> xxx_check(), xxx_set(), xxx_get(), xxx_getmod() callback functions. >> > If I understand correctly, you are suggesting to, for example, have > wladm_set_prop() pass its property and callback table to your new > do_set_prop() > function? > > if so, how will dladm_set_prop() be implemented? > don't you have a circular dependency now? > (i.e. dladm_set_prop()->wladm_set_prop()->do_set_prop()) > (libdladm) (libwladm) (libdladm) > > I think this was the reason we didn't factor out the common code. > maybe we need a separate library to hold your new do_set_prop() code? > Yes. That is a problem.
But I am thinking of this problem for a while: currently we proppse to make the datalink configuration API (the APIs to manage and persist datalink configuration) to be part of libdladm. Then all other libraries will have to depend on libdladm. But at the same time, as it is currently true, libdladm depends on other libraries too. I think we have to introduce another library to hold all the common functions. Team, thoughts? Thanks - Cathy > eric
