> All-in-all I think it's an excellent idea to remove as many tunables as > possible, but when new h/w comes along it's generally necessary to add > them because existing APIs/features within the stack don't quire fit the > model. Those can be modified and the tunables eventually removed, but > this is an iterative process and thus, I believe, Solaris should have > good support for dynamic driver tunables rather than trying to deny > their existence.
I still believe the right balance has been struck. As you imply above, configuration knobs that have staying power will be regularly folded into the core stack, so the per-driver set should remain small and relatively volatile. Again, common configuration infrastructure s critical to the long-term ability to administer networking in Solaris -- we must not get back into the mindset of requiring an administrator to follow different procedures to get up and running with each and every driver. Further to that, I explicitly do not want to build in a discovery -- we did that with ndd and it resulted in poorly-informed fiddling that ultimately led to support calls. The admin should have a problem they're trying to solve when reaching for a driver-specific knob, not just groping and hoping. -- meem _______________________________________________ networking-discuss mailing list [email protected]
