Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Apr 2014 09:03:18 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Jordan Hubbard <jkh@ixsystems.com>
Cc:        freebsd-arch <freebsd-arch@freebsd.org>
Subject:   Re: Compiler toolchain roadmap
Message-ID:  <EFEFB531-6279-41C1-B0BF-A0EA1F722E24@bsdimp.com>
In-Reply-To: <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com>
References:  <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> <2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D@FreeBSD.org> <6A02504F-5543-4F91-92F6-7B4FB9A34DC4@ixsystems.com> <152D73EE-DF9E-4757-B547-F1F22B12C824@FreeBSD.org> <B06E1588-8828-485F-A407-3F19231F8EA5@ixsystems.com> <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> <6418BE83-BE78-473B-9311-C849507FA885@ixsystems.com> <CAJ-Vmom-19LujsTQ%2Bv4XozE%2BiEH18LMEQitBLC-At=DmsgkB%2BQ@mail.gmail.com> <EB9CE8A8-E897-4DE1-A8BC-80C6CC23E612@ixsystems.com> <9E11A6D4-9D18-422D-9514-4714AADDAEF4@gmail.com> <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 7, 2014, at 3:06 AM, Jordan Hubbard <jkh@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.=94

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=92s been the notion in =
the past when using llvm features has come up. The notion for this path =
has always been =91It is possible, but only a subset of the =
functionality may be available.=94

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=92s 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=92d still love to get libdispatch into base =
such that other services can be layered on top of it.  There=92s 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 =93services hub=94 work we=92ll be doing will all depend on =
libdispatch and blocks.

I think you misunderstood. While there=92s 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=92ve made some fixes to but ultimately just had =
to disable entirely (so Samba in FreeNAS will not support kernel =
notifications for awhile), it=92s that bad.  Just judging by the blatant =
nature of the bugs we=92ve found and fixed so far, it=92s also fairly =
clear that nobody has been using that port very much, or very =
intensively.
>=20
> 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=92m more than willing to help drive some of =
that architecture, too, but I sure don=92t want to do it on top of =
pthreads and raw socket I/O. :)

Understandable.

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

I see a continuum of answer here: If you want to modify the kernel =
extensive to use blocks, then that=92s 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=92s sweet spot. I=92m 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=92t =
drive out all innovation in the tree. Where to drop the needle on the =
continuum is an area where there=92s 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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFEFB531-6279-41C1-B0BF-A0EA1F722E24>