From owner-freebsd-hackers Fri Sep 10 5:30:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 9A2401504C for ; Fri, 10 Sep 1999 05:30:18 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from scones.sup.scc.nl (i441.ztm.euronet.nl [194.134.67.162]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id OAA20400; Fri, 10 Sep 1999 14:30:03 +0200 (MET DST) Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id OAA42321; Fri, 10 Sep 1999 14:29:49 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37D8F9BD.E364BDC7@scc.nl> Date: Fri, 10 Sep 1999 14:29:49 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dmitrij Tejblum Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions References: <199909101123.PAA02006@tejblum.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dmitrij Tejblum wrote: > 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.) You can compile programs on -stable and let them run on -current. This holds for both staticly and dynamicly linked binaries. This is what backwards compatibility is all about. Compiling on -current and running on -stable can give you problems. > Now, you are going to break the feature. What do you offer in return? It's not a feature. It happens to be that way sometimes in the chain of events. > 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. FUD. I don't see anyone else complaining. OTOH, I do receive implicit and explicit support in changing sigset_t. > 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. I now understand your point of view. It doesn't really have anything to do with whether or not we should have a version bump. Your arguments are simply rooted in your way of programming and/or compiling and the (false) assumption that you can depend on libc being interchangable across different versions of FreeBSD. > 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. I don't see how your solution can maintain a higher degree of compatibility then a version dump. In both cases you can run -stable binaries on -current but not the other way around. > [perhaps, I will answer the rest of your mail later] I do hope so. I think that adding functions to hide datatype changes have more drawbacks then version bumps, but I may be mistaken. Nonetheless, it's an important issue. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message