From owner-svn-src-all@freebsd.org Tue Aug 23 08:51:56 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B8B7BC1985; Tue, 23 Aug 2016 08:51:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC851653; Tue, 23 Aug 2016 08:51:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OCC00P00TVF9N00@st13p35im-asmtp001.me.com>; Tue, 23 Aug 2016 08:51:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1471942314; bh=Rmtn/KL3D9ovB67ar0N3uhyLAs8ukrdemuli1g5KNRc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Wa8Wjq8vo19BlubS9mb4BU0+GRkFaHq+5T080MTnehOhjVtJ1V4O8R0KnwlNuV580 PI8Xj3yWpN1g6trIWXO+ZtXDA4ZsASHF5FfkvqD5BtAq5P8BB5YJYEH0VOw8kvN5XO hMFjl4jrKwvO+Kw3q364zAT5LpBez5KM2ixAe1ygxcDu8nEt4Oo7ZSmpLsRRf7k8C9 YkSpm2K+RN1gPUcV0PU+ud8ynowTJ+4fNBN4kv00nEGrcV2hB9JwEGk+EsuxvX9ImU 4vDqfmnW4+TSRyAK+bc7wC6bHUvExMT+ubmIlIToeprs7jPSZKGVe+XYhwiGKpXGPG 5OEirx1DCwvMQ== Received: from [88.196.10.91] (91-10-196-88.dyn.estpak.ee [88.196.10.91]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OCC006GCTYF8410@st13p35im-asmtp001.me.com>; Tue, 23 Aug 2016 08:51:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-23_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1608230089 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r304321 - in head/sys: boot/efi/boot1 boot/efi/loader boot/i386/boot2 boot/i386/gptboot boot/i386/gptzfsboot boot/i386/zfsboot boot/userboot/ficl boot/userboot/userboot boot/userboot/zf... From: Toomas Soome In-reply-to: Date: Tue, 23 Aug 2016 11:51:51 +0300 Cc: Warner Losh , Toomas Soome , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-transfer-encoding: quoted-printable Message-id: <3587EDAA-35AE-4D71-8BA4-24C3E0254795@me.com> References: <201608180037.u7I0b77A095653@repo.freebsd.org> <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 08:51:56 -0000 > On 23. aug 2016, at 11:22, Andriy Gapon wrote: >=20 > On 22/08/2016 17:56, Toomas Soome wrote: >> Actually I only now realized I was comparing apples with oranges=E2=80=A6= I forgot >> the fbsd builds 32bit version in ficl32, this one is 64bit. and yes = the 32bit >> version is not that big at all:D >>=20 >> Also, after done some digging, I have found few instances of = duplicated code >> (we can share sha2 with geli and so if sha512 is already needed, it = will >> become another =E2=80=9Cfree lunch=E2=80=9D). Also, unless I=E2=80=99m = mistaken, for some reason the >> bzip *compression* is brought in - correct me if I=E2=80=99m wrong, = but afaik only >> decompression is needed=E2=80=A6 >>=20 >> So before going after =E2=80=9Cuseless features=E2=80=9D, there are = some =E2=80=9Chidden=E2=80=9D resources >> to remove extra fat. >=20 > I certainly agree with this and those things would be good to do. > But if we do not change the trend then sooner or later we will run out = of things > that we can optimize. But it's also possible that the current = limitations will > be a history by then. >=20 > --=20 > Andriy Gapon Yes, also from my illumos work, even building framebuffer based GFX = interface haven=E2=80=99t added too much extra code, but it is important = to recognize the limits, and this issue did provide really good lesson = about it;) Right now there are two tasks to finalize - complete the review/test/fix = for proper compiler options, and to understand the actual limits = regarding userboot module - for me it is absolutely unknown area. rgds, toomas