From: Kent Fredric <kentnl@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Gentoo i486 support
Date: Sat, 25 Aug 2018 02:40:09 +1200 [thread overview]
Message-ID: <20180825024009.03bf8ce3@katipo2.lan> (raw)
In-Reply-To: <CAGfcS_m8VwDwztDPn248B2xfYmAj7K5pZJsPZ7x2Xfb1qLv71g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]
On Fri, 24 Aug 2018 10:13:42 -0400
Rich Freeman <rich0@gentoo.org> 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.
4. For people targeting minimal should-at-least-work-on-i586/i486
binary images, setting CPU_FLAGS_X86="-*" 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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-08-24 14:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-22 12:26 [gentoo-dev] Gentoo i486 support Ben Kohler
2018-08-22 13:08 ` Rich Freeman
2018-08-22 13:23 ` Mart Raudsepp
2018-08-22 14:22 ` Peter Stuge
2018-08-22 20:27 ` R0b0t1
2018-08-22 20:39 ` Rich Freeman
2018-08-25 11:07 ` Andrew Savchenko
2018-08-22 13:21 ` James Le Cuirot
2018-08-22 14:30 ` Mike Gilbert
2018-08-22 15:27 ` Thomas Deutschmann
2018-08-22 19:20 ` Matt Turner
2018-08-22 19:27 ` M. J. Everitt
2018-08-22 20:19 ` Richard Yao
2018-08-24 13:19 ` Kent Fredric
2018-08-24 13:57 ` Mike Gilbert
2018-08-24 14:13 ` Rich Freeman
2018-08-24 14:40 ` Kent Fredric [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180825024009.03bf8ce3@katipo2.lan \
--to=kentnl@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox