Date: Fri, 10 Sep 1999 15:23:42 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Marcel Moolenaar <marcel@scc.nl> Cc: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <199909101123.PAA02006@tejblum.pp.ru> In-Reply-To: Your message of "Fri, 10 Sep 1999 09:36:39 %2B0200." <37D8B507.CC33F50F@scc.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909101123.PAA02006>