Compiler toolchain roadmap

[Jordan Hubbard]

On Apr 7, 2014, at 2:56 AM, Warner Losh <imp at bsdimp.com> wrote:

> First off, nobody every said we can’t have nice things in the tree because of MIPS. Where was that said? It can’t possibly be true because gcc supports blocks in the tree, so there’s no impediment. LLVM-based things? Show me the money and bring one to the table and we can talk, but even then there’s clang support for mips, so again that’s not a big deal.

Perhaps I got lost somewhere along the way during the conversation thread with David Chisnall, but it sounded like we were both in favor of libdispatch and willing to at least grudgingly accept the proposition that we’d never break the deadlock between having an absolute locked-in use case for it first vs having the fundamental technology available and in a position to change the way we do async programming (and perhaps get more dynamism into FreeBSD as a whole) when he said:

"I would certainly be in favour of importing it.  The package seems to be on every FreeBSD machine that I use, so I've become accustomed to having it there and just work.”

Then he followed up with:

"The slight problem, however, is that we would still like to be able to build the base system with a more or less standard C compiler.  Blocks are in clang and are slowly making their way into commercial compilers, but the only two versions of gcc that support them are the ones shipped by Apple and FreeBSD.”

and then:

"For embedded uses, we'd also like to build FreeBSD with vendor's-ugly-hacked-up-gcc-of-the-week.  This is less of an issue now for ARM, but MIPS vendors still hack up gcc in such a way that there's no way that they can get their changes upstreamed and then ship the result with their chips.”

So what I took away from that was that my long and somewhat quixotic attempts to get libdispatch into FreeBSD (notionally scheduled for 8.1, then pushed out indefinitely) would probably remain quixotic due to a desire to keep base buildable by a fairly broad and non-freebsd controlled compiler toolchains in the case of MIPS.   Did I misunderstand something?  I’d still love to get libdispatch into base such that other services can be layered on top of it.  There’s a fundamental reason why we stuck it into Libsystem in OS X, and the notification system and other IPC technologies I'm hoping for as part of the “services hub” work we’ll be doing will all depend on libdispatch and blocks.

This is also, just in case anyone is wondering, far from academic.  Notification services are currently the bane of our existence over in FreeNAS, with services like Samba depending on a very buggy libinotify port for FreeBSD that we’ve made some fixes to but ultimately just had to disable entirely (so Samba in FreeNAS will not support kernel notifications for awhile), it’s that bad.  Just judging by the blatant nature of the bugs we’ve found and fixed so far, it’s also fairly clear that nobody has been using that port very much, or very intensively.

Unfortunately, the mobile computing space (to say nothing of the services space) needs to be a lot more aware of constant environmental changes (network links coming and going, time zones changing on the fly, service pairing relationships being created/broken, etc) and this takes a bit more architecture.  I’m more than willing to help drive some of that architecture, too, but I sure don’t want to do it on top of pthreads and raw socket I/O. :)

- Jordan