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. > > > 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. mph > > thanks, > Dan > > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org
