From owner-freebsd-mips@freebsd.org Thu Dec 13 10:37:22 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCC981316378 for ; Thu, 13 Dec 2018 10:37:21 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD9AE818F9 for ; Thu, 13 Dec 2018 10:37:20 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id EB0B03C475F; Thu, 13 Dec 2018 10:37:12 +0000 (UTC) Date: Thu, 13 Dec 2018 10:37:12 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-mips@freebsd.org" Subject: Re: MIPS future... Message-ID: <20181213103712.GA49957@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: DD9AE818F9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.03 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[spindle.one-eyed-alien.net]; MX_MISSING(3.50)[requested record is not found]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; IP_SCORE(-3.64)[ip: (-9.47), ipnet: 199.48.128.0/22(-4.73), asn: 36236(-3.92), country: US(-0.09)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 10:37:22 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2018 at 11:15:06AM -0700, Warner Losh wrote: > OK. To be a good player in the FreeBSD ecosystem, we need to do a few > things. >=20 > First, we need to implement atomic_swap_64. hps did this for mips64 and > committed it. He sent me some further patches for it that I need to commit > when I get a change, maybe at the airport tonight. >=20 > But this brings up a couple of issues I'd like to bring up. >=20 > First, to implement atomic_swap_64 on mips-32 is hard. In that it's not > just the canonical ldd/sdd sequence because those aren't available there. > We can do the standard trick of reading STATUS0, clearing IE, storing it, > do the operation and then restoring STATUS0. This is efficient enough for > the use in the kernel for the supported cores we have. I think we have to do this no matter how expensive it is or kill 32-bit mips. There is no way there are enough 32-bit mips users to justify even the minor level of developer friction the unr64 caused. > That brings me to my next question: SWARM. Can we kill SWARM entirely? It= 's > for the BCM1250 part, released in sometime before 2000. It was super > popular because it was the reference for a ton of things that followed. I > think it's run is over and we can remove it. I can find no users of it in > the nyc dmesg database. Mine has been in a plastic bag since before my so= ne > was born in 2006... So I'm thinking we can remove this platform. It was on > the edge last time I did a GC in mips-land. It looks like it's a sibyte platform if I read the config files correctly. If so, I seriously doubt it works reliably under meaningful, multi-process load. We built at sibyte-like PIC for BERI and there were quite a few WTF moments as we adapted to code. I don't have strong opinions on the other platforms. I know we haven't used GXEMUL in at least 5 years on our projects. Qemu and the MALTA config does everything we need. -- Brooks --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJcEjZYAAoJEKzQXbSebgfAVo8H/iT6ix1kvvT3vx0mkslVNmze 3ojD72efSze8BJpqNYh0eeSmr2e5dIKupcTDrAAKL97hzK0+6gATexJ4WFHkPokg g/ILwcHETpEkyYLw/TckODzAYo8j/YeOK4NQ8/QS4S417o7oAT3KOHfqJp6dFGKR Hb5qBTqxA1/+l+KG/LwxHgHQjN93BaCylhgyOpjuPMChXhwZTGrg33V7jH0pVz66 +k3j+xBdNTO5xUE/Quj12Cfi/NjSTVDOwINRVGRQYz+xtVUWnEfMQnpNHUoVMd3M B2pq98f09kisi1IkfXJ/+H1TcFRZheYMLuXJq1lCiuG4WibOE1nyvxOUHsDF8oM= =Y8Gn -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--