From owner-freebsd-current@FreeBSD.ORG Sat Nov 15 15:03:41 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6034916A4CF; Sat, 15 Nov 2003 15:03:41 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5CAB43F93; Sat, 15 Nov 2003 15:03:39 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfj2j.dialup.mindspring.com ([165.247.204.83] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AL9S6-00079s-00; Sat, 15 Nov 2003 15:03:39 -0800 Message-ID: <3FB6B0CF.A705268C@mindspring.com> Date: Sat, 15 Nov 2003 15:03:43 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d2204e30ae470601b27da186f946f020a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: current@freebsd.org cc: Munish Chopra cc: kirk@mckusick.com Subject: Re: HEADS-UP new statfs structure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 23:03:41 -0000 Robert Watson wrote: > What's going on is the following: while we have a compatibility system > call in place, it only affects applications linked against non-current > libc. As soon as you recompile libc, applications expecting the old > statfs() ABI get the new statfs(), and depending on where their smaller > struct statfs is located, may stomp on memory they're using for something > else (like critical data structures). This means that any application > using statfs() and linked against libc.so.5 may start having problems. > Not only that, but as you begin to compile new programs, they start > expecting the new statfs() API, so if you keep the old libc, they'll start > expecting to see extended struct statfs information in a structure that's > too small. This is almost certainly a less harmful failure mode than the > former. However, it turns out statfs() is used in a fair number of > applications (and libraries)... I recently ran into a similar need to break the API without breaking the ABI. The easiest way to do this is to add a new system call, with a different name, and scope the changeover to compile time. At some later point, when you bump the libc version, you can change the name to the new name, and deprecate the old. For the "statfs" case, here's the example: % nm /usr/lib/libc.a | grep "T _statfs" 00000008 T _statfs 00000008 T _statfs_new % grep statfs /usr/include/sys/mount.h #define statfs statfs_new int statfs(const char *, struct statfs *); Viola! Recompile, get the new, don't recompile, get the old. The only place this breaks is sucky programs that define the structure without including the header file to get the prototype and #define in scope as well. -- Terry