From owner-freebsd-mips@freebsd.org Thu Dec 13 17:45:49 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 AE81C132E14D for ; Thu, 13 Dec 2018 17:45:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A4F46AB47; Thu, 13 Dec 2018 17:45:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBDHjWOH079863; Thu, 13 Dec 2018 09:45:32 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBDHjWbT079862; Thu, 13 Dec 2018 09:45:32 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812131745.wBDHjWbT079862@pdx.rh.CN85.dnsmgr.net> Subject: Re: MIPS future... In-Reply-To: To: Warner Losh Date: Thu, 13 Dec 2018 09:45:31 -0800 (PST) CC: Brooks Davis , freebsd-mips@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 0A4F46AB47 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.87 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.23)[0.232,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.77)[0.774,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.03)[asn: 13868(-0.04), country: US(-0.09)] 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 17:45:50 -0000 > On Thu, Dec 13, 2018, 3:37 AM Brooks Davis > > 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. > > > > > > 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. > > > > > > But this brings up a couple of issues I'd like to bring up. > > > > > > 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. > > > > Yes. That's the plan. The question is how. And part of that how is giving > up on mips32 ISA (and requiring mips32r2 or newer). So I'll be doing that. > We have one SMP platform for 32bit mips that will have to die. It is only 4 > years old, but the design never caught on. Please verify that none of the MIPS based router (wifi-build, and router project) stuff is killed, these are usefull, and I believe active work is going on in both. Last time I played with wifi-build I was able to boot a 8MB image on a d-link router and had a working implementation, this was when 12 was head. Sean Bruno may know about here, he was the one that fixed some of the issues I had run into since Adrian Chad is just too busy with "life and kids :-)". > > > 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 > > sone > > > 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. > > > > That confirms my expectations. It was shakey back in the day, and it can > only be worse now... > > 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. > > > > Ok. I think gxemul users have moved to qemu and the burden of supporting > two emulators is too great. > > Warner -- Rod Grimes rgrimes@freebsd.org