MIPS future...

[Rodney W. Grimes]

> On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <brooks at 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 at freebsd.org