Compiler toolchain roadmap

[Warner Losh]

On Apr 7, 2014, at 3:06 AM, Jordan Hubbard <jkh at ixsystems.com> wrote:

> "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.”

This is a desire, not a hard requirement. As such, there may be missing bits if you chose to go this route. At least that’s been the notion in the past when using llvm features has come up. The notion for this path has always been ‘It is possible, but only a subset of the functionality may be available.”

So if one were to add blocks, it would need a knob WITHOUT_BLOCKS that would disable all functionality tied to them. For many applications, this is a reasonable subset (based on my guesses at how intrusive this would be to the system). And it might even be automatically selected based on compiler support, but that’s another can of worms.

> 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.

I think you misunderstood. While there’s a desire to be able to build from vendor supplied gcc for latest and greatest silicon, that desire has consequences. We already have a number of FreeBSD extensions in the compiler, and those would have to be disabled for this vendor supplied gcc compiler.

> 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. :)

Understandable.

So to take this a step further… There’s many levels of integration here…  First, there’s the kernel, which is most often the bit of code people want/need the special compiler for. Next, there’s having the feature available in user land. Finally, there’d be a wide-scale integration of this feature. I see very few programs in base benefiting from libdispatch, honestly, but that doesn’t mean the set is empty. Do you have a longer write up on what you’d like to do here?

I see a continuum of answer here: If you want to modify the kernel extensive to use blocks, then that’s going to be a much bigger problem than having a few daemons and a library in the tree that require them which is a bigger problem than having a few daemons using it, but optionally, and a library which is a bigger problem than a library in the tree which is a bigger problem than the status quo. Somewhere along this continuum will be FreeBSD’s sweet spot. I’m guessing it might be on the second notch (no wide-spread kernel changes to fundamental bits, but with daemons that require it to work at all) or third notch (daemons still work, but work better, faster, harder with blocks).

So I do agree with you in many ways: this crazy fringe desire shouldn’t drive out all innovation in the tree. Where to drop the needle on the continuum is an area where there’s a rough, fuzzy consensus, but a more concrete set of code desiring to be in the tree is needed.

And 8.1 for libdispatch? Is it really so portable it would work with our old, crappy gcc pre blocks update?

Warner