Date: Wed, 13 Mar 2002 08:46:20 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Julian Elischer <julian@elischer.org> Cc: Maxim Konovalov <maxim@macomnet.ru>, Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.ORG Subject: Re: eaccess(2) breaks execution of 4.x binaries on 5.x Message-ID: <Pine.NEB.3.96L.1020313083923.36618J-100000@fledge.watson.org> 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 Tue, 12 Mar 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) Yes, the problem here is that Kris is building and running a 5.x world on a 4.x kernel in a chroot to support the build cluster. Common binaries such as sh are just now beginning to rely on the new kernel functionality (a trend that will continue, as I pointed out), and my belief is the model being used is flawed as anything other than a short term thing. On the other hand, there's no harm in MFC'ing eaccess(), since it's a generally useful thing. However, as soon as the 64-bit UFS2 work starts coming in, and the new system calls are brought in to support that, even basic applications such as 'sh' are going to stop working again, due to stat(). But my feeling is that's actually OK given the direction: 4.x kernel 5.x kernel 4.x binaries REQUIRED REQUIRED 5.x binaries DEGRADING REQUIRED This case falls squarely into the 'DEGRADING' category, given the approach of new functionality. For example, ls will shortly learn about ACL system calls, which while present in the -STABLE aren't implemented. Likewise, configure scripts that test the behavior of system calls will also start failing in appropriately. To get us 5.0-DP1 packages, sure, MFC eaccess(). We'll just need to make sure that over the next month or two, -CURRENT is in a position where it can run safely on the package cluster to support 5.0 package builds. I can MFC eaccess() later today, assuming there are no objections. I've been meaning to for a while, so that I can merge it into Darwin. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1020313083923.36618J-100000>