Date: Thu, 13 Dec 2018 09:45:31 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: Brooks Davis <brooks@freebsd.org>, freebsd-mips@freebsd.org Subject: Re: MIPS future... Message-ID: <201812131745.wBDHjWbT079862@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CANCZdfqTsf62dcecF3vhg1CBrx1BMuW9v_pASEWvVnmwNGKg0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <brooks@freebsd.org wrote: > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812131745.wBDHjWbT079862>