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>; 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) - 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? - Where should i_dladm_rw_db go? Should it stay where it is? - Does anyone see any potential problems with this approach? thanks, Dan
