From owner-dev-commits-src-branches@freebsd.org Fri Feb 5 20:26:01 2021 Return-Path: Delivered-To: dev-commits-src-branches@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 219B2529598 for ; Fri, 5 Feb 2021 20:26:01 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXRkx03bzz4V7l for ; Fri, 5 Feb 2021 20:26:00 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: by mail-wr1-f45.google.com with SMTP id d16so9032868wro.11 for ; Fri, 05 Feb 2021 12:26:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hcZB/9ER0d7HW414f5dvOlXvkYUP+L8mV/Jym18iz3Y=; b=pZj9yeWfmmv6P7ufNMa4Yw6clLSjZLpLBuwjoaeYRH3Q7AYgk71JROjrtZ2gdvFPDa fbFEDzVuoto6wbi99ut65E5+6qERToiAfdL3LVsSbXUc7isKI+z9iPABOVoAhegj4qev 3WEhlJ9EIi2Mo55zsAr3rKhPxRYlpuz3bNDfw/Hbw2vPhXX8caeImj4Kj3sKkbovfl+8 PVGhPs2NVpygS3ntMjZMQIOd0sZB9gLXfVV2zw7nd1/581+az9f3L6573v3fHNBCqRkD tvvZxOkAQLDQrGgNNeCxfbNL+czcFQI/9vcj0oyKQ42VyJosawxTxCZ0U/0lLX0pkRUo CzeA== X-Gm-Message-State: AOAM531Mkl6Q6RcMg7worUKZi3jdjY9CmhYWVmQSVyIIHasGuUxGf8L4 80Pxp6YjuHiCqcuy+K2/TuEwcQ== X-Google-Smtp-Source: ABdhPJzS1GD/ytChZge60aAM10DlBJEoyAAeQzrZKCE44R4z9LfD574k43ilfcUx4BT3IKEVmHePow== X-Received: by 2002:a5d:4a11:: with SMTP id m17mr6714571wrq.39.1612556759465; Fri, 05 Feb 2021 12:25:59 -0800 (PST) Received: from [192.168.149.251] (trinity-students-nat.trin.cam.ac.uk. [131.111.193.104]) by smtp.gmail.com with ESMTPSA id w25sm9981726wmc.42.2021.02.05.12.25.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2021 12:25:58 -0800 (PST) From: Jessica Clarke Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev Date: Fri, 5 Feb 2021 20:25:56 +0000 In-Reply-To: Cc: Toomas Soome , Toomas Soome , src-committers , "" , dev-commits-src-branches@freebsd.org To: Warner Losh References: <97F5C09F-7AE3-4763-AD32-BFEA25101CE5@me.com> <014891C8-7B1F-4908-9495-2ED1A5FAABCF@me.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4DXRkx03bzz4V7l X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: dev-commits-src-branches@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commits to the stable branches of the FreeBSD src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:26:01 -0000 > On 5 Feb 2021, at 20:21, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome > wrote: >=20 >=20 >> On 5. Feb 2021, at 21:43, Warner Losh > wrote: >>=20 >>=20 >>=20 >> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome > wrote: >>=20 >>=20 >>> On 5. Feb 2021, at 18:44, Warner Losh > wrote: >>>=20 >>>=20 >>>=20 >>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome > wrote: >>>=20 >>>=20 >>>> On 5. Feb 2021, at 01:56, Warner Losh > wrote: >>>>=20 >>>> =EF=BB=BF >>>> And why the instaMFC? Changes are supposed to cook force days = before merging... I have questions about the wisdom of this change... >>>>=20 >>>> Warner=20 >>>>=20 >>>=20 >>> Reason is in PR. There is someone with the system without ConOut but = ConOutDev is set. Instead of falling back to arbitrary device (which in = this case was totally wrong choice), we can try the possible devices = list. We do not change the ConOut parsing. >>>=20 >>> We could have the same effect defaulting to Video. This bug should = have been discussed / reviewed before it was committed. >>=20 >> How is is different from defaulting to serial, it is just as bad? we = can not guess there, thats why we do have ConOutDev list. >>=20 >>=20 >>>=20 >>> If it would appear, there are systems with unusable devices listed = in ConOutDev, then we need to think how to handle such case. >>>=20 >>> Yes. We fall back to the arbitrary device... It's just a flag that = can be overridden. We can easily fall back to video too. >>=20 >> We *should not* fall back on arbitrary devices when there is source = for alternate options. And that option is from specification: >>=20 >> "The ConInDev, ConOutDev, and ErrOutDev variables each contain an = EFI_DEVICE_PATH_PROTOCOL descriptor that defines all the possible = default devices to use on boot. These variables are volatile, and are = set dynamically on every boot. ConIn, ConOut, and ErrOut are always = proper subsets of ConInDev, ConOutDev, and ErrOutDev.=E2=80=9D >>=20 >> Right. Except they aren't a proper subset in this case. Since they = aren't a proper subset, can you count on them having any meaningful = meaning? In the cases you found they do, but it's just as arbitrary. >=20 > Well, we can argue if empty set is or is not subset of (any) other = set. But, we do have specification. And we should not arbitrary pick = what part we are going to follow and what not. >=20 > The empty set isn't a proper subset. It is a subset, but not a proper = subset, by definition. Therefore, it's not standards complaint. The empty set is a proper subset of any non-empty set. Proper just means = that it's not equal to the original set. Perhaps you're thinking of = trivial subsets (which are the empty set and, if not empty, the original = set)? Jess