From owner-freebsd-current Tue Mar 12 21:48:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 6275237B404; Tue, 12 Mar 2002 21:48:48 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g2D5meQ8469865; Wed, 13 Mar 2002 08:48:40 +0300 (MSK) Date: Wed, 13 Mar 2002 08:48:40 +0300 (MSK) From: Maxim Konovalov To: Julian Elischer Cc: Kris Kennaway , Robert Watson , Subject: Re: eaccess(2) breaks execution of 4.x binaries on 5.x In-Reply-To: Message-ID: <20020313084344.Y25680-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 21:33-0800, Mar 12, 2002, Julian Elischer wrote: > any change that has to be added to 4.x tomake it run on 5.x is the wrong > answer. > 4.x binaries should all run on 5.x (unless something was accidentally > committed to 4.x that should be backed out.) > > any change for allowing 4.x binaries to run on 5.x should be done on the > 5.x side of things, > (unless I've misunderstood the problem here) I believe you have :-) Kris cannot run /bin/sh from 5.x on 4.x because of absence eaccess(2) in 4.x. > regards, Julian > > > On Wed, 13 Mar 2002, Maxim Konovalov wrote: > > > > > Kris, Robert, > > > > On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote: > > > > > On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote: > > > > > > > > On Tue, 12 Mar 2002, Kris Kennaway wrote: > > > > > > > > > Subject says it all, really; this is the cause of part of my problems in > > > > > getting 5.x packages built on the bento cluster, because it seems that > > > > > /bin/sh has come to depend on this syscall. Executing a 5.x /bin/sh on > > > > > a 4.x system causes a SIGSYS if it hits this code (e.g. test -x > > > > > /some/binary) > > > > > > > > > > Can this syscall be MFCed soon? > > > > > > > > Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls, > > > > MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ... > > > > > > > > Certainly we can MFC eaccess(), but that's not going to make the problem > > > > go away. Fundamentally our model is backward compatibility, not forward > > > > compatibility. We need to build 5.0 packages on 5.0. > > > > > > Well, I've backed out the eaccess() use in /bin/test for now. I agree > > > with you that ultimately this model will fail, but the longer we can > > > delay it the easier my life will be trying to manage the cluster and > > > get packages built. > > > > I can replace my eaccess(2) patch for test(1) by a workaround I am > > planning to commit to -stable. Is it desirable solution? > > > > Index: test.c > > =================================================================== > > RCS file: /home/ncvs/src/bin/test/test.c,v > > retrieving revision 1.29.2.4 [...] -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message