>>> 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? > This is a private configuration file, why cannot we store information whichever way we prefer?
> [...] >>> 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)? > Or we could have a separate function to update and read the datalink.conf file. I agree the logic is similar to i_dladm_rw_db(). But I don't have preference either way. - Cathy
