Michael Hunter wrote: > On Mon, 29 Jan 2007 15:54:49 -0500 > Dan Groves <Daniel.Groves at Sun.COM> wrote: > >> >> Michael Hunter wrote: >>> On Fri, 26 Jan 2007 16:53:34 -0500 >>> Dan Groves <Daniel.Groves at Sun.COM> wrote: >>> >>>> I posted a new copy of the link ID management document to >>>> >>>> http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf >>>> >>>> It includes modifications for all comments received so far except for >>>> the request from Cathy about a way to get at class information for a >>>> temporary link. I'll add changes for that after she's responded to my >>>> proposal. >>> How are you going to deal with alignment issues for storage of different >>> types in dladm_get_conf? Check and return error, fault in lib, >>> copy safely and let the user fault on access? >>> >> I was going to go with the last option. That's similar to the way the >> kstat library works. I'm not sure what an API user would do with an >> error code in this case. I never considered a fault in the library >> because I planned to use memcpys to move the data around. > > I agree that the first option isn't really in line with how > applications are usu. written. I personally like the access faulting > in the users code if possible. If this choice is part of the interface > contract with the user it should be made explicit in your document so > that future changes to the implementation do the right thing. >
I will add a comment to the description of dladm_get_conf_field. >>> Any reason not to have a return parameter containing the data type in >>> dladm_get_conf? Its shouldn't be necessary but I could see it >>> simplifying some generic coding tasks. If added you should allow a >>> null pointer to be passed for this parameter. >>> >> I thought about adding an argument for the data type, but I couldn't >> think of a reason to do it. What tasks do you have in mind? > > It could simplify code which did data driven walking of configuration > parameters. But thats probably a stretch. > OK, I'll add a new parameter. I'm not sure how often it will be used, so I'll state that it can be NULL, in which case nothing is returned. thanks, Dan
