Date: Mon, 12 Feb 2001 17:31:24 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: -CURRENT is bad for me... Message-ID: <Pine.SUN.3.91.1010212172122.15702A-100000@pcnet1.pcnet.com> In-Reply-To: <200102122220.f1CMKUm01666@mass.dis.org>
index | next in thread | previous in thread | raw e-mail
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 messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010212172122.15702A-100000>