From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 15:03:27 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42261DA9 for ; Mon, 7 Apr 2014 15:03:27 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1CA6AC1 for ; Mon, 7 Apr 2014 15:03:26 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wn1so6609021obc.39 for ; Mon, 07 Apr 2014 08:03:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tQoiiosKny/KYrqJ4RU1ayKbIS+PNloOv8JCsZ+cLLU=; b=QHzn6vyNnzXE/n4tHBAZf8LTsQ4wwosmpH1lPSHjr+g00sRTWI/UmzxRAOBaRom0r6 JmYWOcNodf7/I2yyKmlky3pA4rI7IpW2U4ADnCVSCOZnqdPhsPEEpvtYcW6a4X/t90WO xvchz/AnYQsjb8qVwyNXTOhQlgaxANH7BywpRWPoF/q2aKNgJIPZpqoRFikxpoQaB/q/ R1cBMY6U8mLwndO9czU2mpo3y2lEnpFn5BYdPigM1fuvqsxEIa0KFJSqVXVUsk5t58qu ZPO4cGq2gg6+KwH64hX2VeK5yCp1L5btOHqwXzWTUuq67phQTf+ajj+HHsr+69PgxCPj xCTw== X-Gm-Message-State: ALoCoQkKMhS9+0qKBA5hYPpcY/xJYmD8q0cLu95l7s/G1g80lYMPt3r+E6pjbFyZ5neWdfc7ppBO X-Received: by 10.182.55.103 with SMTP id r7mr1047923obp.78.1396883000201; Mon, 07 Apr 2014 08:03:20 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id h3sm13128780obh.8.2014.04.07.08.03.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 08:03:19 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Compiler toolchain roadmap From: Warner Losh In-Reply-To: <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com> Date: Mon, 7 Apr 2014 09:03:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <8E22F8FA-CF71-4A47-BDE8-F3CE6158E1C9@ixsystems.com> To: Jordan Hubbard 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 15:03:27 -0000 On Apr 7, 2014, at 3:06 AM, Jordan Hubbard 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=