From owner-freebsd-hackers Fri Sep 10 4:22:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 0966F14EB8 for ; Fri, 10 Sep 1999 04:22:38 -0700 (PDT) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id PAA33370; Fri, 10 Sep 1999 15:21:12 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id PAA02006; Fri, 10 Sep 1999 15:23:42 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Message-Id: <199909101123.PAA02006@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Marcel Moolenaar Cc: Dmitrij Tejblum , hackers@FreeBSD.ORG From: Dmitrij Tejblum Subject: Re: 32+ signals and library versions In-reply-to: Your message of "Fri, 10 Sep 1999 09:36:39 +0200." <37D8B507.CC33F50F@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Date: Fri, 10 Sep 1999 15:23:42 +0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > You have the problem; you also have the solution. I don't want the complete > history of development bundled in a library. That's my problem. Now tell me > how do I solve it? Well, yes, this is a problem, and I cannot offer a solution. I only will say the following only as a consolation: you are already having the complete history of development in the kernel, so you have this problem anyway, admittely of a different size. Then, every time you say "recompile!", you partially defeat the purpose of the compatibility in the kernel - you are forcing the people to quickly get rid of most old binaries anyway. > > You described the existing situation. You could notice that I suggest to > > change it. > > Strange. You are the one that is also refering to rules and standards that > are in use now and you are using that to validate your point. Now you are > telling me that you actually are diverting from the rules and a proposing a > change? Why am I having this discussion? FreeBSD 4.0 currently have a nice feature - libc compatibility with FreeBSD 3.x. That is, I can link a program build on 3.x with the libc build from src/lib/libc on -current, either dynamically or statically. I also can do it in other way around. I _use_ this feature every day. (Note: this feature is traditional. You was mostly able to do the same with 2.2.x and 3.0 (if you stuck with aout) - the major version number was not bumped in 3.0. You actually could do the same with 2.1 and 2.2 - the incompatibility between libc.so.2.2 and libc.so.3.0 was mostly imaginary, and people used to symlink libc.so.2.2 to libc.so.3.0 and most program worked.) Now, you are going to break the feature. What do you offer in return? 32+ signals. I am probably not going to use the new feature. You hardly will find a lot of people who desperately need it: most people don't care at all, most of other would need to deal with 3.x with only 32 signals anyway. OTOH, the compatibility feature will be more important for quite a few people when 4.0-BETA and 4.0-RELEASE will be released. So, I don't think it is a reasonable tradeoff. Thus, I object. Please don't break the compatibility. Perhaps, restrict it to kernel internals and the linux emulator, if you need it for linux emulation. The solution I suggest, of course, will partially break the compatibility feature anyway. But only in a relative small part. This may be a reasonable tradeoff. If you just don't want to implement the thing I suggest - OK. I am willing to do it myself (but "not today"). [perhaps, I will answer the rest of your mail later] Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message