Date: Mon, 7 Apr 2014 14:06:12 +0500 From: Jordan Hubbard <jkh@ixsystems.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Compiler toolchain roadmap Message-ID: <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com> In-Reply-To: <9E11A6D4-9D18-422D-9514-4714AADDAEF4@gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 7, 2014, at 2:56 AM, Warner Losh <imp@bsdimp.com> wrote: > First off, nobody every said we can=92t have nice things in the tree = because of MIPS. Where was that said? It can=92t possibly be true = because gcc supports blocks in the tree, so there=92s no impediment. = LLVM-based things? Show me the money and bring one to the table and we = can talk, but even then there=92s clang support for mips, so again = that=92s 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=92d 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.=94 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.=94 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.=94 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. 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. 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. :) - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9>