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? > > > We store type information so that the current API does not have to > change. Similar to the problems I ran into with SMF, converting to > text to store in the flat file is easy, but without type information > in the flat file, it is impossible to convert from text back to the > original type without some sort of translation table in the code. > That translation table makes it difficult to extend the code. > > I would put this code under src/cmd/linkmgmtd in a new file: > linkmgmtd_repository_interface.c. > > The linkprop.c code refers to a function i_dladm_rw_db which is in > usr/src/lib/libdladm/common/libdladm.c (in both the Project Clearview > gate and the Nevada gate). i_dladm_rw_db provides locking and > provides some protection against a system crash in the middle of > trying to write to the file. The function does not process the file, > that is handled by a callback function passed into the i_dladm_rw_db > function. > > It would be rather strange to have linkmgmtd call into i_dladm_rw_db, > which is currently in libdladm. It could be done, and would be fairly > easy to expose that function. However, it would make more sense to > more this function elsewhere. Remember, the write requests linkmgmtd > receives are a result of a door call from libdladm. I would rather > move it. > > 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. > > - change linkprop.c so that it can interface with linkmgmtd's data > structures. I have removed all the unnecessary code from a copy of > linkprop.c in my workspace > - integrate linkmgmt_repository_interface.c with linkmgmtd. > - get rename working with the flat file > - test > > Questions/Requests: > > - There has to be a better name than linkmgmt_repository_interface.c. > Suggestions? I don't like this name, but I don't have better suggestion either. - Cathy > - Where should i_dladm_rw_db go? Should it stay where it is? > - Does anyone see any potential problems with this approach? > > thanks, > Dan > > > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org
