IMO nothing intended to be tunable by any customer should require the use of mdb or destructive dtrace. There has to be a safe interface for administrative actions and neither of those are it.
Today I can tell the services guys to ask the customer to perform an ndd query to obtain settings, or set a specific variable using ndd. (virtually a game of chinese whispers). Such instructions are easily followed and errors are non fatal. mdb in particular is like using a tactical nuke to kill a fly, you don't want a typo to ruin your day, particularly on a production server running your bank. -George *>Date: Wed, 16 Apr 2008 11:47:40 -0400 *>From: [EMAIL PROTECTED] *>Subject: [networking-discuss] replacing/cleaning ndd at the tcp/ip layer *>To: [email protected] *>MIME-version: 1.0 *>Content-transfer-encoding: 7BIT *>Content-disposition: inline *>X-BeenThere: [email protected] *>Delivered-to: [email protected] *>X-PMX-Version: 5.4.1.325704 *>X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on oss-mail1.opensolaris.org *>X-Original-To: [email protected] *>X-Antispam: No, score=-2.6/5.0, scanned in 0.082sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ *>X-Mailman-Version: 2.1.9 *>X-Authentication-warning: quasimodo.East.Sun.COM: sowmini set sender to [EMAIL PROTECTED] using -f *>List-Post: <mailto:[email protected]> *>List-Subscribe: <http://mail.opensolaris.org/mailman/listinfo/networking-discuss>, <mailto:[EMAIL PROTECTED]> *>List-Unsubscribe: <http://mail.opensolaris.org/mailman/listinfo/networking-discuss>, <mailto:[EMAIL PROTECTED]> *>List-Archive: <http://mail.opensolaris.org/pipermail/networking-discuss> *>List-Help: <mailto:[EMAIL PROTECTED]> *>List-Id: Networking General Discussion <networking-discuss.opensolaris.org> *>User-Agent: Mutt/1.5.17 (2008-01-17) *>X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,RCVD_IN_DNSWL_LOW autolearn=unavailable version=3.2.3 *>X-Spam-Level: *> *> *>Now that Brussels has provided an alternative for ndd at the *>datalink layer, it is time to re-examine the appropriateness of *>some of the ndd tunables in the TCP/IP layer. ndd has *>taken on many "tunables" that should have been implemented *>with mdb/dtrace, or implemented by other methods. *> *>I'm trying to compile a list of the current ndd vars *>to identify the true tunables from the ones that *>are confusing debug knobs or diagnostic hooks. *> *>It's still work-in-progress (lots of empty cells *>waiting for content) but please send any comments my way, *>so that we can clean up ndd and potentially evaluate what *>ndd (or its replacement candidate) must/should/must-not *>deal with. *> *>Help with filling up the cells would also be welcome, *>of course! *> *>Location of table: *> http://cr.opensolaris.org/~sowmini/ndd.html *> *>--Sowmini *> *>_______________________________________________ *>networking-discuss mailing list *>[email protected] George Shepherd http://clem.uk/~georges/ ============================================================================== Solaris Revenue Product Engineering: | SUN Microsystems Core team -Internet | Guillemont Park Email: [EMAIL PROTECTED] | Camberley GU17 9QG Disclaimer: Less is more, more or less | United Kingdom ============================================================================== _______________________________________________ networking-discuss mailing list [email protected]
