Date: Sun, 6 Jul 1997 18:39:48 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: kent@erlang.ericsson.se Subject: Re: Application os version compatibility? Message-ID: <19970706183948.WI18973@uriah.heep.sax.de> In-Reply-To: <199707061132.NAA29134@townsend.ericsson.se>; from Kent Boortz on Jul 6, 1997 13:32:37 %2B0200 References: <Pine.BSF.3.95q.970705200828.12420C-100000@misery.sdf.com> <199707061132.NAA29134@townsend.ericsson.se>
next in thread | previous in thread | raw e-mail | index | archive | help
As Kent Boortz wrote: > Could it be the case that a new system call is added from FreeBSD > X.X.1 to X.X.2 and for example a new libc.a implement fopen() with > this new call? New functions (or new syscalls) will bump libc's minor number. > Then running even statically linked applications > compiled in X.X.2 running on X.X.1 will break, right? Yes, in this sense, only upwards compatibility is guaranteed. > Do the behaviour of system calls *ever* change change in an > incompatible way? Normally not. Even when moving from 4.3BSD (32 bit off_t) to 4.4BSD (64 bit off_t), the old syscalls have been retained. (The have an `o' prepended inside the kernel, and the new syscalls have been given new slots in the syscall vector.) There was only one oversight, using the syscall fcntl(2) with the file locking commands breaks it, since there's no new fcntl call. Apart from this, FreeBSD 1.x (BSD/Net2) binaries still run on FreeBSD 2 (4.4BSD). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970706183948.WI18973>