Cathy Zhou wrote: > Dan Groves ??: >> Hi, >> >> I've decided that the linkprop.c code in libdladm will be the basis >> for the flat file for storing link configuration information that I'm >> prototyping. Note that the version of linkprop.c in the Project >> Clearview gate no longer has code in it to parse or write >> /etc/dladm/linkprop.c, so I'm using the linkprop.c in the Nevada gate >> as my basis. When I mention linkprop.c, the Nevada gate version is >> the version I'm referring to unless I state otherwise. >> >> The parsing code already supports name-value pairs, or actually >> name-value0-value1-...-valueN sets. The format I'm proposing is: >> >> <linkname>\t<prop0>=<type>,<val>;<prop1>=<type>,<val>;...;<propN>=<type>,<val>; >> >> > Why note be: > > linkid name=string,<val>; ... > > So that renaming operation would be simpler?
Right, but do we want to go that route? I agree it would be simpler, and I like that, but do we want to identify the entry that way? [...] >> For the flat file route, I would need to: >> >> - move i_dladm_rw_db and associated code (optional, but strongly desired) > I agree to move that function to linkmgmtd, and rename the function to > be not prefixed with dladm. [...] We can't move it to linkmgmtd, the secobj.conf code in libdladm still uses i_dladm_rw_db. Sorry, I should have mentioned that as a consideration in moving it. Maybe we should have a separate library for i_dladm_rw_db (and then as you suggest, change the function name)? thanks, Dan
