Darren Reed writes: > Please explain to me how having some value that is used in IP > is worse off for being used via a variable (that can be tuned.) > Exactly what is this "baggage"?
Having a tunable that's never actually used just wastes space and promotes confusion. Customers often *do* tweak random variables without actually understanding what they do, and then get themselves into all sorts of trouble as a result. The output of the magic "?" variable in ndd is just too much in their faces. I'm not saying we should Windows-ize everything and make the system an unmanageable black box. That'd be dumb. But we should also look at what we're providing and see if it makes sense. If it doesn't, then fix it, where "fix" might mean making the tunable usable with a different granularity (some are system-wide but should perhaps be per-socket instead), or perhaps just nuking it if it's pointless. That's the thinking underlying both the original dladm and Brussels work, as well as this new work. Since ndd cruft carries a lot of baggage with it (a noticeable bit of code and often design consideration for new features as well, in addition to a lack of any stable way to make changes that survive reboot and lots of admin folklore), attacking these makes sense. In many cases, the "problems" that the variables were addressing either have long since left the planet, have been overtaken by other technology (such as ICMP rate limits), or just never existed at all (many seem to have been added on spec). Perhaps in *some* cases, it may make sense to "demote" some of the variables from ndd to /etc/system rather than just converting straight to a #define. Yes, I realize /etc/system is system-wide and thus might not be what you want with exclusive stack instance zones, and that it lacks range controls. So what? If we're talking about a variable that's "never" used in practice, and we're retaining it just for future emergencies, then supporting exclusive stack instance zones is just an unnecessary elaboration. Plus, relegating it to /etc/system automatically fixes the surviving-reboot problem, and the in-the-admin's-face problem, so it's a positive step. In other cases, just deleting would be better. Like that VHF fine tuning knob. You ain't gonna need it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
