Cathy Zhou wrote: > >>>> 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? >
True. I'll do it 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)? >> > 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. > OK. We won't need the locking part of i_dladm_rw_db, but we will need the part that correctly updates the file, and prevents (or attempts to prevent) loss of data during a write operation. Dan
