From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 30 00:37:23 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B7C2467; Mon, 30 Mar 2015 00:37:23 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4944164; Mon, 30 Mar 2015 00:37:22 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so157971024pdb.1; Sun, 29 Mar 2015 17:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=EI0kd7C018moX8ljN0SoqGvJxqpkDIJjHi/qKRbIhpY=; b=WBkV5Qr3ydezjnuam1FtDythHDiuG7gV67+ztXO70akJMXfzL06eDH7AhMd1R6B+R3 sDrY4nrw6xm4IZLR5nDnwpWi640+cD9ixnGDwPuwp2HJ6MOeTl2mYOgTCt7Gt+PLgET8 Xqk+Ru1/BFyav/5sHhS5OQoJrX5ECCnClLBY4dRRfMll6ZvdYCN2G0Fob6tKWAaNsYsL 0n5M+JLgjrXRntsk5OMGJz5sOupEEBcvegqz9w6pCfVCARuCTjwvYoESiNke6NUS8JjA jnhgNlHVu7PW3PiKuGy/T8ejmI4RS3kgvZZeX3IqWZNGCPs/zqmYu7tjOX3QDlImbie/ PGOg== X-Received: by 10.68.90.132 with SMTP id bw4mr53347655pbb.102.1427675842160; Sun, 29 Mar 2015 17:37:22 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id hs4sm8556193pbc.79.2015.03.29.17.37.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 17:37:21 -0700 (PDT) References: <20683705-0EBA-4B8F-A0CE-9C06B8003BBE@FreeBSD.org> <20150329082734.GA13058@vlakno.cz> <7A9A90EA-E052-425E-BE90-9290B0CAB03F@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7A9A90EA-E052-425E-BE90-9290B0CAB03F@bsdimp.com> Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Message-Id: <32F42F43-0AFA-4562-B845-4612D123742E@gmail.com> X-Mailer: iPhone Mail (12D508) From: Garrett Cooper Subject: Re: Fails to build sys/i386/boot2 with gcc 4.9 Date: Sun, 29 Mar 2015 17:37:18 -0700 To: Warner Losh Cc: "freebsd-testing@freebsd.org" , FreeBSD Toolchain , Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 00:37:23 -0000 > On Mar 29, 2015, at 15:56, Warner Losh wrote: >=20 >> On Mar 29, 2015, at 2:29 PM, Craig Rodrigues wrote:= >>=20 >> On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh wrote: >>=20 >> If we built a UFS1-only boot2, that would fit in the 7.5k we have left >> to play with. We could then build a UFS2-only boot2 that would easily >> fit in the like 32k limit that UFS2 has. >>=20 >> The only reason we went to supporting both was to have something >> universal. Since it requires a reformat to go from UFS1 -> UFS2 we >> wanted the transition to be as smooth as possible so you didn=81ft have >> to add boot blocks into the mix. >>=20 >> Now the only people that use UFS1 are people with really old systems >> that are never going to upgrade, or people building new systems with >> UFS1 because they are space constrained (for whatever reasons that >> we=81fre not going to debate here: they are still real). >>=20 >> In the past 5 years, I have worked on some embedded systems where UFS1 wa= s chosen because of very low memory and disk space requirements. >> So those systems are real and out there. >>=20 >> Just out of curiousity, what is it about newer compilers that cause >> the size of boot2 to increase so much? >>=20 >> Could we do some silly things like removing/reducing the use of printf() >> to save some more bytes, in order to buy us more time, before having >> to rewrite everything? :) >=20 > Removing printf isn=81ft going to save us. It usually compiles to 80-120 b= ytes. >=20 > I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe > some safety belts in the boot block splatter programs to prevent > brickification. Since the proposal to split up the code by filesystems is on the table, woul= d it make sense to do something similar for zfs? Thanks!=