From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 09:06:29 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD6601C4 for ; Mon, 7 Apr 2014 09:06:29 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4C4FEF1 for ; Mon, 7 Apr 2014 09:06:29 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id BE5B072F7C; Mon, 7 Apr 2014 02:06:27 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 75693-01; Mon, 7 Apr 2014 02:06:27 -0700 (PDT) Received: from [10.8.0.22] (unknown [10.8.0.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 8F80C72F72; Mon, 7 Apr 2014 02:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396861587; bh=/5RvYXW8QyMnV1/NfQP961BNT7uLiKSWl0qcUVssR1k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tWP23QylWXhfbrQCWwFhPW7R1UdbOkdePp/Es1TROd3V8ie0rCj5w8lxNOLpMpQec o7/72pMDE8O6Iwd5dC2tqWvLGWSacqa5NOBVemJU8vBGKBPenZO3qpn2PlFrdNlEQS MeWoGSLTj5ztNcrL+/w0VIWG44UMNYF4PQLT7fh4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Compiler toolchain roadmap From: Jordan Hubbard In-Reply-To: <9E11A6D4-9D18-422D-9514-4714AADDAEF4@gmail.com> Date: Mon, 7 Apr 2014 14:06:12 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <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> <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> <6418BE83-BE78-473B-9311-C849507FA885@ixsystems.com> <9E11A6D4-9D18-422D-9514-4714AADDAEF4@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.1874) Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:06:29 -0000 On Apr 7, 2014, at 2:56 AM, Warner Losh 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