From nobody Mon Feb 21 21:05:21 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C864319DF365 for ; Mon, 21 Feb 2022 21:00:50 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2ZTF6sY1z4Trp for ; Mon, 21 Feb 2022 21:00:49 +0000 (UTC) (envelope-from pj@smo.de) Received: from localhost (localhost [127.0.0.1]) by mail.adebahr.de (Postfix) with ESMTP id D2DF260327120 for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=smo.de; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id; s=mail; t= 1645477241; x=1647291642; bh=++mjs54O6uLXgfj+UVaiXcor880jlh03arQ eDMx7ap8=; b=z9njQ5pfBKPwr9kB9pOpqfEy0RRciFHxZ3oCriL6zGo9+tRBeCl xt3j5w0+Gxc7yTkP65ijspkCw7v2ZPnlUMr4/hi9unsIrDgYpkD+eQEJhLb4h32G cnQpBncCr8JBpgDZPwf4c9ns6Ff0mh57mq3ekYsOGxW7L0PRcFHCC2hw= Received: from mail.adebahr.de ([127.0.0.1]) by localhost (mail.adebahr.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id ZOe3Zqu75A0Q for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) Received: from [192.168.153.212] (p4fe02b24.dip0.t-ipconnect.de [79.224.43.36]) by mail.adebahr.de (Postfix) with ESMTPSA id 9F8A960327128 for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) Message-ID: <0c2419e7-925f-7648-865b-86328009cf29@smo.de> Date: Mon, 21 Feb 2022 22:05:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) Content-Language: en-US To: freebsd-current@freebsd.org References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> <16051.1645463921@kaos.jnpr.net> From: Philipp Ost In-Reply-To: <16051.1645463921@kaos.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K2ZTF6sY1z4Trp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=z9njQ5pf; dmarc=pass (policy=reject) header.from=smo.de; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[smo.de:+]; DMARC_POLICY_ALLOW(-0.50)[smo.de,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:198930, ipnet:185.66.176.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.224.43.36:received] X-ThisMailContainsUnwantedMimeParts: N On 2/21/22 18:18, Simon J. Gerraty wrote: > Toomas Soome wrote: >>> Why should pxeboot have ZFS support? >> >> Well, the feature X can be helpful for recovery purposes. The root >> cause is not the feature X itself, but the size limit. And the >> unfortunate fact, the size limit is not fixed, but depends on the >> system. Therefore there are two options - either to fix the size limit >> or drop option X from default build — at least till the size limit is >> fixed (or support for BIOS will be dropped). > > Or just build separate variants. > As Bjoern said Lua is probably the straw breaking the cammel's back > but I think it reasonable to assume that a system that has the resources > to support ZFS does not have an ancient BIOS ? I have several machines in use which are capable of supporting ZFS just fine and all of these have a BIOS. Just saying. ;-)