From owner-freebsd-current Mon Feb 12 17:28:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id EC7E937B491 for ; Mon, 12 Feb 2001 17:28:41 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f1D1SWm02448; Mon, 12 Feb 2001 17:28:32 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102130128.f1D1SWm02448@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter Wemm Cc: Alex Zepeda , current@FreeBSD.ORG Subject: Re: -CURRENT is bad for me... In-reply-to: Your message of "Mon, 12 Feb 2001 17:22:17 PST." <200102130122.f1D1MIU56283@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Feb 2001 17:28:32 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: > > > > > > > You can do better than this. Put the lock in FILE, and define a new > > > > structure FILE_old, which has the same size/layout as the old FILE > > > > structure. > > > > > > How is this more acceptable than bumping the major number? Are they > > > really so precious that they can only be incremented once for a release > > > cycle? Seems to me that a new major number is far cleaner than a gross hac > k. > > > > The major number has ALREADY BEEN BUMPED. > > > > The "gross hack" is a transitional step necessary for the upgrade path to > > work, and would be removed after it was no longer required. > > The "gross hack" can *NEVER* be removed and will live on through 5.0-RELEASE > and 5.0-STABLE, because we *continue* to compile in the wrong sizes into > applications. Er, no, we wouldn't do this. The "gross hack" ensures binary compatibility with old applications. It's up to you or someone else to fix the source-level implementation of stdin/out/err such that it's not dependant on the size of the new FILE structure. This is the same as, for example, renaming an ioctl to keep an old interface alive. Newly compiled code uses the new interface, not the old one. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message