-HEAD on gxemul/MALTA is broken

[Joe Holden]

Juli Mallett wrote:
> On Wed, Apr 17, 2013 at 6:05 PM, Joe Holden <lists at rewt.org.uk> wrote:
>> I reported this as a pr for Octeon, I'm seeing the same thing - no response
>> yet though.... is MIPS ever likely to be a well supported platform given
>> nobody pays attention?
> 
> FreeBSD on MIPS is unfortunately not just one platform, and the name
> is a little misleading.  There is substantial difference between the
> code for Octeon, XLR/XLP, the Atheros SoCs and other board-support
> packages.  It's easy for quirks of one or more to go unnoticed, or for
> someone to be fixed in one without realizing that the fix is also
> required in fairly-different code on another.
> 
> We're talking about -CURRENT, too, which is a moving target.  I
> wouldn't suggest using a -STABLE branch for MIPS.  I know several
> companies using FreeBSD on MIPS without constant issues — I don't
> think they'd argue that it's not a well-supported platform.  What
> they've done is more effort than the average casual user is likely to
> put in, which is to identify a point-in-time at which things are
> mostly working for them, identify the right people to contact to get
> their major issues fixed, and then stay with that version for some
> time, rather than either trying to track top-of-tree or getting stuck
> with limited support in -STABLE.
> 
> I run -CURRENT on Octeon on dozens of boards from time to time, but on
> an ongoing basis on just two.  It's mostly stable, although I do
> notice some crashes on long-term uptime, and as I've mentioned to
> several people in private, getting the most out of Octeon requires at
> least doing a lot of your network processing in the kernel, or ideally
> writing some slightly-specialized software.
> 
> I have a Broadcom board that I run occasionally, a couple of Atheros
> ones, and probably a few others I'm forgetting.
> 
> It's understandable that when just starting to use a port of FreeBSD
> -CURRENT to MIPS, on finding one or two things broken, to figure that
> (1) it's never worked (2) it's broken for everyone.  Both obviously
> lead to the conclusion that nobody cares, and that things are
> incomplete and unmaintained.
> 
> But the amount of hardware FreeBSD/MIPS supports is incredible.  I've
> personally run FreeBSD/MIPS on perhaps two dozen different hardware
> configurations, and have helped people run it on probably a dozen
> more.  That's just stuff I take some responsibility for.  I know of
> perhaps a hundred more that FreeBSD runs on.
> 
> As for not paying attention: I don't update very often, and my focus
> is really mostly on FreeBSD on Octeon when I can afford to pay any
> attention at all.  Adrian pays a lot of attention, but his focus is
> mostly on Atheros hardware; he's able to spend the time and have
> hardware access in part because of his relationship with that company.
>  There are others in similar positions, such as jchandra who puts in
> huge amounts of work on RMI/NetLogic-based hardware, and with me has
> done a lot of work on expanding 64-bit support and improving
> performance.  Neel has lots of other responsibilities, but has handled
> a lot of work on keeping various MIPS hardware platforms working, as
> well as being responsible for things like a fairly robust SMP
> abstraction for MIPS, and the first real work on SMP FreeBSD/MIPS,
> which made it a matter of hours for me to add SMP support for Octeon.
> 
> What kind of attention would you like to be paid?  How much latency in
> addressing issues do you think is acceptable?  How much work do you
> think it's reasonable to expect users to do to get up and running with
> what are, almost exclusively, embedded platforms?  It may be that the
> answer here is that we should wait for pfSense MIPS support to become
> widely-available and stable, with ready-to-use images.
> 
> FreeBSD/MIPS doesn't even come with a package set, as you know; it's
> not a one-click operating system, it's more like an operating system
> base.
> 
> Is it likely that FreeBSD/MIPS will become more usable?  Yes.  Due to
> tremendous amounts of volunteer labour from people who don't have a
> lot of spare time, and the occasional burst of academic or commercial
> support which allows for significant improvement to occur in a short
> period of time.
> 
> I try to find others to get involved (like Pat Kelsey who has been
> very active in responding to SD and MMC threads since I hired him to
> support MMC over SPI, which was a crucial missing feature on several
> popular Atheros-based boards.)  It's not always easy; sometimes
> people's priorities or foci change, as with one engineer I was
> delighted to be working with from a major SoC vendor, who stopped
> answering E-Mails after committing some of his work had to be delayed
> due to license issues with some code his employer wanted him to
> commit.  Whether he got reassigned, his bosses soured on FreeBSD's
> inability to accept GPL'd Linux code into the kernel, or he simply
> felt there was nothing left to do, I don't know.
> 
> Being an open source developer is a lot more than waiting around for
> bug reports to arrive and then fixing them.  Even in paid software
> development that isn't how it works; things get prioritized, and often
> dealt with opportunistically.  There's cases where in my paid work
> I've known about a bug for years before I've had time to fix it
> because other, more pressing issues keep coming up.  And in open
> source work, we're not just dealing with prioritizing work, dealing
> with long-term planning, putting out fires, trying to keep up with
> others' changes, and deal with bug-fixing.  We also help to enable
> each other to work better, and to become involved, and to stay
> involved, and to fix things.  I'm happiest when I'm able to help
> others work on things they're excited about, and I think that's when
> I'm doing my best work as a developer of open source software.  Fixing
> bugs is essential, but it's not always what there's resources for,
> especially when FreeBSD gets, speaking for myself, such a slim sliver
> of my time, because I have so much else on my plate.
> 
> I do the best I can.  If you can do better, I'd be thrilled to help
> you get more involved with FreeBSD.  I can respond to E-Mails about
> things you're passionate about or interested in when I have no time,
> or energy, or focus, to update to -CURRENT and make sure everything's
> working great.  I would love to see you become a FreeBSD developer and
> make it better.  It doesn't get better magically, but through the
> commitment and hard work of people like you, or where that's not your
> skill, through applying whatever yours is.  Maybe you can help fund
> work; maybe you can find bugs and hound people to get them fixed.
> Making sure bugs gets fixed is important work, that requires
> discipline and focus; it isn't every software developer's gift, and if
> it's one you have, I'd encourage you to make use of it.  Don't be
> afraid to harangue people for breaking -CURRENT, but I'd discourage
> vague insinuations of poor quality because you've hit a couple of
> roadbumps.  (Which is not to say those roadbumps should be there, but
> to ask whose responsibility you think it is to level them.)
> 
> I can't do as much as I like, but in addition to supporting other
> non-profit causes that are important to me, I give money to the
> FreeBSD Foundation.  Their focus isn't FreeBSD/MIPS as such, but I'm
> pretty confident that they'd help fund FreeBSD/MIPS projects if you
> can find someone interested in working on them.  I benefit a lot from
> the work I put into FreeBSD; I have had several jobs pretty much
> entirely because of it.  FreeBSD means a lot to me and I don't want it
> to suck, but there's only so much I can do.  So I don't just take all
> FreeBSD has to give me: an operating system to run, a regular (read:
> overwhelming) supply of paid work, etc.  I find ways to give back.
> 
> I'm sorry for the length, but I think it's important to be very clear
> about two things: (1) it's people like you who help make FreeBSD
> better (2) they work very hard doing it, and the success of that work
> should not be underestimated, even if it is somewhat undermined when
> -CURRENT is so routinely in crap shape.  I suggest specific and
> regular technical complaints, though, over insinuations that we simply
> don't care, or don't pay attention.
> 
> I want to end there, but I'll say this: in addition to a few messages
> from you, I've had half a dozen more this week alone from people who
> need help with some aspect or another of FreeBSD on Octeon (getting
> hardware, supporting new boards, improving the port, getting started,
> etc.)  I don't even have time to respond to all of them so much as
> they deserve, but I do the best I can.  (Which means that I usually
> respond to FreeBSD-related E-Mail ahead of other personal
> correspondance because it's important to me to try to do so.)  On top
> of that, dozens more messages related to FreeBSD in general, including
> work that I'm funding, work that I'm doing, and the work that I (and
> most other developers) do reading and reviewing and responding to
> changes made to FreeBSD.
> 
> Thanks,
> Juli.
When I said attention, I meant more as a platform, I realise it's not 
quite a Tier 1 arch but even arm has it's own category etc for problem 
reports - not attempting to devalue the enormous amount of work both you 
and others do, not just for MIPS but in general.

I guess really I just expected the same as seen for example amd64...

Either way, overly facetious comment - no offense intended and apologies 
if it did offend.

Thanks