> On (06/19/07 17:32), Dan Groves wrote: > >> 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. >> > > Do you mean linkprop.conf in the paragraph above? It's a bit confusing > because you seem to be referring to both "/etc/dladm/linkprop.c" and > code in "linkprop.c". > I think Dan means the code linkprop.c used to use to persist data-link configuration. As we decide to persist data-link in the flat-file format, the code will be pretty much alike the code in linkprop.c today.
Note that how to organize the respository should be completely implementation detail, and other project should simply use the link management API (for example, dladm_read_conf(), dladm_set_conf_field()) to persist data-link configuration. > >> 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. >> > > the i_dladm_rw_db in nevada is called from > 2 linkprop.c i_dladm_set_prop_db 699 return (LINKPROP_RW_DB(&state, B_TRUE)); > 3 linkprop.c i_dladm_get_prop_db 714 return (LINKPROP_RW_DB(&state, B_FALSE)); > 4 linkprop.c dladm_init_linkprop 728 return (LINKPROP_RW_DB(&state, B_FALSE)); > > Is this function going to be moved to some other library? I'm not > sure I follow your proposal. > I don't think i_dladm_set_prop_db() etc. will exist any more. But Dan should be the person to clarify that. > >> 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. >> > > It sounds like you would either have to link libdladm into libdladmd, > or link the new library into dladm (and other programs that invoke > libdladm- e.g., nwamd). If I understand your proposal correctly, > it might be easier (since nwamd is also using dladm_init_linkprop) > to just add -ldladm to the Makefile in linkmgmtd. > > >> Questions/Requests: >> >> - Where should i_dladm_rw_db go? Should it stay where it is? Again, I think it is just implemenation of the configuration persistence. If the persistance is only going to initiated from linkmgmtd, I would think that is the place to place the function. -- Cathy >> >> I would say, yes. >> >> --Sowmini >> >> >> _________________________________ >> clearview-discuss mailing list >> clearview-discuss at opensolaris.org >>
