From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C4799138334 for ; Fri, 24 Aug 2018 14:40:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A83EE0969; Fri, 24 Aug 2018 14:40:38 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1D1C6E0827 for ; Fri, 24 Aug 2018 14:40:38 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id D868F335C7D for ; Fri, 24 Aug 2018 14:40:35 +0000 (UTC) Date: Sat, 25 Aug 2018 02:40:09 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo i486 support Message-ID: <20180825024009.03bf8ce3@katipo2.lan> In-Reply-To: References: <5cc35530-3d96-1a0f-b484-73ea3d58bed5@gentoo.org> <20180825011945.254bb9ca@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/I+DuFS5./1TUUZ6hl0YiPbN"; protocol="application/pgp-signature" X-Archives-Salt: 6d6ed8d5-36c6-4f81-900c-ea6120460549 X-Archives-Hash: 4288a79eaaa76376d271373a1cce8b48 --Sig_/I+DuFS5./1TUUZ6hl0YiPbN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Aug 2018 10:13:42 -0400 Rich Freeman wrote: > I think an exp arch is also overkill. How many packages simply can't > be built for i486? I think a profile+masking makes a lot more sense > than an entire new level of QA that touches every ebuild in the tree > because there might be a few packages that don't work on 25 year old > hardware. In response to other conversations on #gentoo-x86, I think neither are needed any more. All that's needed to target this set is as follows: 1. Focus on the problem in terms of CPU instruction feature sets and memory limitations. 2. Make sure packages that don't work on i586 natively due to lack of instructions, and require adjustment, utilize CPU_FLAGS_X86 to expose this issue, ( eg: sse, mmx, cmov ) 3. Make the CPU_FLAGS_X86 generator tool emits the ideal values when run locally on a given processor.=20 4. For people targeting minimal should-at-least-work-on-i586/i486 binary images, setting CPU_FLAGS_X86=3D"-*" should be recommended. 5. For people targeting physically ancient platforms with binary media, it might be pertinent to standardize on some sort of USE flag to indicate to applicable packages to optimize for runtime-memory-constrained environments. Or something along those lines. This should avoid all the downsides of new-arches/new profiles, while still allowing ebuilds to introspect and customize themselves as needed. Additionally, the features not being bound to a profile means they can be mixed and matched across profiles, so a memory-constrained environment targeting i686/mips/arm can use the same controls. And users who have, for example, CPUs' *with* the cmov instruction, but an inferior/slow implementation, can opt-out of using that instruction. And then using these tools we can throw minimal-flag-sets and minimal-memory at stage builds. --Sig_/I+DuFS5./1TUUZ6hl0YiPbN Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAluAGNYACgkQda6SGagV g7WJSw//Z9a14I2+XeGMqE6+Mo/LuMHyDsDQyPhRleBFM9XtlpjTgVTQqoyp2yQ3 RN4LSqvp1pEdF4ajzxVyVEo3rl+j4fKgpSqsPen3yR1UwVy5KzTm/+UGPYpAEP6p rFior7ABNkcKbdiEHrcTKwSdrv/L2aPmcE5jdasEVzieq9G7Hj6Hd0FAN+HOa1wd RF8pvp0K3aYK6C8ZFUd7ZyafqXNXIlrqlTK4EKrN8ptTwYGDmY/Q8WpnA3hYRk5F uSvmOyeqL7yoiNhCJ6Y5vEMXED9if78wFyttWbeDq7OGwLuHE0MQM/+6HY//2gtO MiVRuw3Y3lDYkXR2F5T2hBoqYECcYTNJUyV/SXnE4WiRV/nhd7QCu8m5EeLRBJ9v nyq3NIot7sjIJ6zeuz2rMNLNhNSUaSIikb/4Ro8+yI9OaQRUZ/+AYEf+lK7sM04w wcS1LLGj9lNoQyCYpY7LdicEm961aQceh/icdYtqcDttvolS0tg0rdGgc3LcQxT0 atJ6CZ382gvBNHS7biJEDUSTOdrghYWUQIUIzhoEZTTCzk5L9xir2SJstaOuA1We XS22GstBX3gpPlNDxS4Y5zzLWOa6mR2yBoLVaazACRhjIWaBPlrPOUHYitU+EdVD tucCyEA3n183VbwrkOX34HwJxIqMGkwFeMRdfoRMU09YEoQh77k= =3u8G -----END PGP SIGNATURE----- --Sig_/I+DuFS5./1TUUZ6hl0YiPbN--