Date: Mon, 12 Feb 2001 17:10:58 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Warner Losh <imp@harmony.village.org> Cc: John Indra <john@office.naver.co.id>, freebsd-current@FreeBSD.ORG Subject: Re: -CURRENT is bad for me... Message-ID: <Pine.SUN.3.91.1010212170101.11435B-100000@pcnet1.pcnet.com> In-Reply-To: <200102122150.f1CLoWW31812@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Feb 2001, Warner Losh wrote: > In message <Pine.SUN.3.91.1010212162702.5225B-100000@pcnet1.pcnet.com> Daniel Eischen writes: > : On Mon, 12 Feb 2001, Warner Losh wrote: > : > To be blunt, the FILE * changes go too far, even for -current. > : > : Other than having to installworld twice, I've had zero problems. > : But I don't recompile my applications often, and am probably > : still running things that depend on libc.so.4. > > I have lots of binaries that depend on libc.so.5 (I just checked) and > none that depend on libc.so.4 or libc.so.3 (since those were removed > from my system a while ago). I suspect many of them will break. > > : > Changes of this magnitude require a bump of the major number, even > : > though we've already done that in -current. It breaks nearly > : > everything, including the upgrade path. Alternatively, the locking > : > changes need to be backed out. > : > : Too bad ELF libraries don't have minor version numbers. It's > : a shame to waste a library version number. > > Don't think of it as a waste. > > : > Alternatively, the upgrade path must be fixed. We've managed to avoid > : > extra special instructions in the vast majority of cases, and I don't > : > want to start introducing them now. It is the road to madness. We > : > tried that once before and the support load was too high. > : > : I don't have the time or resources to fix the upgrade path. If > : someone else wants to, it would certainly be appreciated. > > 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? 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. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010212170101.11435B-100000>