On 03/05/09 13:38, Peter Memishian wrote: > > I was thinking the same. Above model would just work fine if we want to > > use libscf.so/svc.configd to just store the interface configurations and > > not represent any of the IP interfaces as SMF instance(s). > > > > > > > Certainly, moving the configuration to SCF doesn't require representing > > > individual IP interfaces as service instances > > > > but is it OK, to just have one aspect of SMF (configuration part) and > > not have any instances of the service which represent the configuration > > i. e. use SMF's configuration framework and not use SMF's service > > management (start, stop, refresh) framework. > > FWIW, the SMF team (and Shapiro in particular) were extremely opposed to > using SMF as a "dumping ground" (his words, IIRC) for networking state. > > There is a lot of history here. As I mentioned earlier in this thread, > there's also a lot that the Fishworks team has learned operationally from > implementing their interfaces-as-instances model. How serious are you > about going in this direction? > Well lets not forget the scope and big-picture of 'ipadm' project. Moving to SMF and making interfaces-as-instances is definitely outside the scope of what it was initially envisioned to do.
I am just trying to understand how 'feasible' it is to move to SCF for now and then as a separate project do interfaces-as-instances model. ~Girish
