From owner-freebsd-current Mon Feb 12 14:32: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D06C537B4EC; Mon, 12 Feb 2001 14:31:48 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA17144; Mon, 12 Feb 2001 17:31:25 -0500 (EST) Date: Mon, 12 Feb 2001 17:31:24 -0500 (EST) From: Daniel Eischen To: Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: Re: -CURRENT is bad for me... In-Reply-To: <200102122220.f1CMKUm01666@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Feb 2001, Mike Smith wrote: > > > Then wouldn't the "partially applied patch" rule apply? eg, back it > > > out until the issues can be resolved. Breaking the upgrade path isn't > > > acceptible. > > > > If you bump the library versions, doesn't that fix the upgrade > > path? > > No, because the library version bump has already happened. It was suggested we bump it again. > > I can think of a gross hack that gets around the problem for > > now. Allocate the FILE with enough storage for the lock, but > > don't declare it in FILE. __sF[3] would still be the same > > size and we could have __sF_locks[3] internally, and use these > > if fp is stdin, stdout, or stderr, else the lock is at the end > > of the struct. > > 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. > > Now, __sF is defined as an array of FILE_old and handled specially > internally (this part is gross, but necessary). You'll have to put the > lock, etc. in a separate array and handle it specially, or you can have > real FILE structures shadowing the FILE_old structures. This is exactly what I was suggesting above, except I wasn't going to publicize the "new" FILE, just use it internally where it was needed (findfp.c, _flock_stub.c, etc). > Because this is a hack for binary compatibility and upgrading only, you > can throw it away before we actually get to 5.0. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message