From owner-cvs-all@FreeBSD.ORG Fri Jun 18 07:46:43 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D68216A4CF for ; Fri, 18 Jun 2004 07:46:43 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BFB1943D46 for ; Fri, 18 Jun 2004 07:46:42 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 47415 invoked from network); 18 Jun 2004 07:46:27 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 18 Jun 2004 07:46:27 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 18 Jun 2004 02:46:26 -0500 (CDT) From: Mike Silbersack To: Ken Smith In-Reply-To: <20040618063319.GB17749@electra.cse.Buffalo.EDU> Message-ID: <20040618014912.O72823@odysseus.silby.com> References: <200406170008.i5H08NDt085108@repoman.freebsd.org> <20040617182031.GA8170@samodelkin.net> <20040617204813.GA10670@samodelkin.net> <20040617214827.GB6029@electra.cse.Buffalo.EDU> <7071.208.178.23.220.1087509793.squirrel@208.178.23.220> <20040618063319.GB17749@electra.cse.Buffalo.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@freebsd.org cc: Alfred Perlstein cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: Max Khon Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c uipc_syscalls.c src/usr.bin/netstat mbuf.c src/lib/libc/sys sendfile.2 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 07:46:43 -0000 On Fri, 18 Jun 2004, Ken Smith wrote: > This is where we disagree and I don't think either of us will change > our minds. My take on it is that this breaks an API in a -stable > branch and is adding new functionality so it *should* be added as > a new flag. Using a slight variant on your ls example, your approach > is like adding the ability to find out what the inode number is by > adding a new column to the output of "ls -l". But they didn't do > that, they added the -i flag. If they had added it to the output > of the -l flag anyone parsing the "ls -l" output in a script would > need to accomodate the extra field. IMHO that's acceptable in > -current, not -stable and IMHO the new information should go in > as a new flag. You're right, my ls example was too inflamatory; netstat -m is clearly different than ls. > Your opinion is obviously different, doesn't look like that will > change. > > -- > Ken Smith My opinion is based on the fact that software in contrib/ and in ports/ can change greatly from version to version, yet I'm getting attacked because I added a few lines of extra information to a utility. Look at the release notes from the last few releases in the 4.x branch; we've imported new versions of bind, sendmail, openssh, binutils, gcc, some utilities have been converted from perl to C, tar, tcpdump, and the list goes on. Especially in the case of converted utilities, it's possible that subtle bugs were added, bugs that could silently cause problems. In the case of adding output to netstat -m, what could possibly happen? Maybe someone's mbuf monitoring script sets a false alarm - the user logs in to check the situation, finds out that sfbuf output was added, fixes the script, and life goes on. This isn't a terrible ABI breakage, it's just a few extra lines of information in the middle of some information that was never meant to be machine parsed. FWIW, netstat -m is variable depending on usage anyway - a different number of lines of output will be printed depending on the types of mbufs that are allocated in the system; take a look at the mbtypenames structure in src/usr.bin/netstat/mbuf.c. Mike "Silby" Silbersack