Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Mar 2002 08:48:40 +0300 (MSK)
From:      Maxim Konovalov <maxim@macomnet.ru>
To:        Julian Elischer <julian@elischer.org>
Cc:        Kris Kennaway <kris@obsecurity.org>, Robert Watson <rwatson@FreeBSD.ORG>, <current@FreeBSD.ORG>
Subject:   Re: eaccess(2) breaks execution of 4.x binaries on 5.x
Message-ID:  <20020313084344.Y25680-100000@news1.macomnet.ru>
In-Reply-To: <Pine.BSF.4.21.0203122131420.72756-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020313084344.Y25680-100000>