[email protected] wrote: > On (03/21/09 14:58), Steven Stallion wrote: >> Would it be possible to add in some verbiage about the persistence >> lifecycle for driver developers? > > I'm not seeing why driver developers would have to ever consider > the persistence lifecycle for the IP interfaces (since these are IP > properties, not driver props). Can you clarify what you have in mind?
Provided a driver is written using the Phase I interfaces, m_getprop/m_setprop may be called at any time (from an API perspective). AFAIK most devices do not support dynamic reconfiguration - meaning that most drivers tend to reset/reconfigure the device if m_setprop has been called after the interface has been started. I think its important to codify precisely when persisted properties are set on a given interface. Provided these are set after the plumb, and before m_start is called, this is fine. If these are done after the interface has started, this could be a serious drag on performance for those drivers which reset when a single property has been changed. Perhaps now that persistence is in the picture, the Phase I interfaces should be updated to support setting a batch of properties (m_setpropv?) - this would reduce the number of device resets. > However the answer to your next question describes the life-cycle > >> Are persisted interface properties assigned post-plumb but pre-up? > > yes, the properties will be applied after IP is plumbed, but before > the interface is marked up. This is good. Is it possible to document this specifically? MAC drivers rely on the Brussels framework - detailing lifecycle is a good thing for those of us who arent intimately familiar with the project. >> Does the modification of properties and runtime stay the same as in Phase I? > > There are some simplifications possible for global props > because IP is never unloaded- (see Section 4). As for per-interface props, > the current model only allows these to be modified when the interface > is plumbed for IP (and will reapply the settings if the interface is > unplumbed/plumbed). This constraint may be relaxed in the future, as we > expand the design to allow more flexible configuration models. This does not affect driver properties so my response likely has no bearing, but... It makes me a little nervous to rely on a given module always being available (or unloadable). It is certainly foreseeable to see an installation which does not make use of IP. Regards, Steve _______________________________________________ networking-discuss mailing list [email protected]
