* James Carlson <james.d.carlson at Sun.COM> [2008-03-07 18:12]: > Joost Mulders writes: > > I have no opinion about temporary instances, but I do have another > > concern about this statement: > > > > > This means storing the configuration data in SMF ... > > > > When SMF was introduced I remember the general feedback from customers > > being "great as long as it doesn't become a big giant registry blob". > > I fully agree with that. > > I agree that complex and detailed configuration (think: BGP policy in > Quagga) likely has no place in SMF because the semantics just aren't > rich enough, but surely basic configuration parameters for the system > services do belong there, right? > > Or are all of the projects that've placed those parameters there > already (such as Greenline's changes to inetd, or the routeadm > changes), and the ones that plan to do it in the future (NWAM at one > point was talking about it for interfaces), and the original SMF > project itself (which discussed migrating configuration over time) all > misguided? > > I had thought that the reason we treat all new configuration files > (/etc/dladm/*) as Private was that they're just a temporary expediency > until they can be redesigned into SMF. Is that not the case?
It is the case (and your summary is accurate). System software designed by and for OpenSolaris should use SMF for its configuration store. We do not force application or layered system service configuration into SMF, although we think there's value in the latter. System services that originate elsewhere and are ported to OpenSolaris consolidations are the tricky ones, where only a configuration subset may get moved, or the entire configuration, or merely enabled/disabled... - Stephen -- sch at sun.com http://blogs.sun.com/sch/
