Date: Mon, 17 Jan 2005 19:24:36 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Scott Long <scottl@freebsd.org> Cc: freebsd-amd64@freebsd.org Subject: Re: [RFC] what to name linux 32-bit compat Message-ID: <20050118032436.GA5325@odin.ac.hmc.edu> In-Reply-To: <41EC7D01.2070107@freebsd.org> References: <20050117203818.GA29131@dragon.nuxi.com> <200501172146.17965.jhb@FreeBSD.org> <41EC7D01.2070107@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 17, 2005 at 08:05:37PM -0700, Scott Long wrote: > John Baldwin wrote: >=20 > >On Monday 17 January 2005 03:38 pm, David O'Brien wrote: > > > >>[ Respect the Reply-to:! ] > >> > >>/usr/ports Linux 32-bit compatibility on AMD64 is a mess and too rough > >>for what is expected of FreeBSD. Anyway... > >> > >>We need to decide how to have both Linux i686 and Linux amd64 compat > >>support live side-by-side. At the moment my leanings are for > >>/compat/linux32 and /compat/linux. We could also go with /compat/linux > >>and /compat/linux64 <- taking a page from the Linux LSB naming conventi= on > >>(ie, they have lib and lib64). > >> > >>Linux 32-bit support is most interesting -- that is how we get Acrobat > >>reader and some other binary-only ports. The only Linux 64-bit things = we > >>might want to run that truly matter 32-bit vs. 64-bit is Oracle and > >>IBM-DB2. For other applications 32-bit vs. 64-bit is mostly a "Just > >>Because Its There(tm)" thing. So making Linux 32-bit support the > >>cleanest looking from a /usr/ports POV has some merit. > >> > >>What do others think? > > > > > >Personally, I think /compat/linux32 and /compat/linux (for linux64) woul= d=20 > >be the best way to go. The idea being that /compat/linux runs native=20 > >binaries on any given arch, and if there's more than one arch supported,= =20 > >the non-native ones get the funky names. I don't think it will really= =20 > >matter all to the end user much as acroread goes in /usr/local/bin and i= s=20 > >in the path and that's all the user has to worry about. The ports stuff= =20 > >to put linux32 in /compat/linux32 on amd64 is going to be stuff the user= =20 > >doesn't have to worry or care about, so I don't think there's any=20 > >user-visible benefit to linux and linux64 versus linux32 and linux. > > >=20 > Having different naming schemes for identical bits is risks confusion > and inconsistency for both ports mainainers and ports users. I agree > that your scheme is attractive, but I think that consistency is more > important. Also, I'd say that we should probably think about leaning in > the direction of the LSB for linux compat. So my vote is that on all > platforms, /compat/linux is for 32-bit and /compat/linux64 is for > 64-bit. I think this is a stretch. By this argument we should really be using /compat/linux-i386 and /compat/linux-amd64 (or would that be x86-64 since that's that linux calls it). I suspect that if Intel doesn't kill ia64 entirely, we will be looking at machines where linux64 is potentially ambiguous in the not too distant a future. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB7IFzXY6L6fI4GtQRArslAJ48XXXk4EudBBUC7RgzH7Mt8QoeHACgt0EM ilR2PSUvv9e91j0XkjUiy20= =+2+n -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050118032436.GA5325>