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>