From owner-dev-commits-src-branches@freebsd.org Fri Feb 5 20:28:38 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 492BA529649 for ; Fri, 5 Feb 2021 20:28:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 4DXRny1HSmz4Vn2 for ; Fri, 5 Feb 2021 20:28:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id x81so8296373qkb.0 for ; Fri, 05 Feb 2021 12:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9cDzxxaoaqNvi8c4xHh4L5Xcdvn7rwTTsZ2JgJdMo3E=; b=bPfC96bE/fxLUoGRbk6ALk1JZKUGY39Gyz3XxiK4KDxob4Ne2spjx02sQ2FQiDJDnR QOz1M3ByjbA9rCw9xMTLQqXNZf0UAogpapuUsVc58lV8x0Suc/wjaSebCAPJm+/elR9j EChZdRN905HyaRbsDCJYSlx/+STP90FsXdUhkttosnKujwG3nrl2UBWaA5Wit27FVJsZ L8p3i7IxoxeHXCmgo7PRH6EWst4hcV9ncH9pZnStkN0LOOhi3tZRoXhGaSUfczLnX2yk unR3OAKMnPXuITiI1Rp/ofgujxnOiWGU9LzVVIYd0w7Vj0IzqaPN5CQNMu/HPcl8Qt9Z prtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9cDzxxaoaqNvi8c4xHh4L5Xcdvn7rwTTsZ2JgJdMo3E=; b=uXiUKgi+pYlxOzECgGkl0TgY1wiX3jFYecMyFaZ6Yy155TI1J7KJ7PrfIZQEdUGqlm 3g7F6G9hZP4BJKG+hQrz6jSQy9XttvTuwYyxY0/FVRjznczVd5MyW38PMwnsRQeEjqXz sbBKb199H7YMWSHxOozk+LziSYcEr7pT4jcrdku2EOpn8GDE9I4JdhvoepY2tQE1vGdI aUXsri3s2eb/WdTKmsqYWuvJEiU86z1+lH5SCPBlugRYu8/mIiJGDGxWHYvslNQ1hM1h 1ioKwg370NUiUpAH+zvrVAA3Cold0CkNVX5uybPK+62ocCB+VyEe+6LTfvJDX8eZP7LQ QwKg== X-Gm-Message-State: AOAM531+yDQcfjhSA/gAaK9D/ACBI/CNbvLGcfaRfEE7gRblYmBCk4qU AASI+1us8hICBjdUvsMw7iHul6M+1fAJavSHkq1dIw== X-Google-Smtp-Source: ABdhPJyBN5iOjYDObbjg7cCD0FlatJ7IlB6hWS141ztQRPFt7nzYaSnfYeNskG5keRntxUqNEW8ytrC/Jm4eAv5RmPY= X-Received: by 2002:a37:a34f:: with SMTP id m76mr6053390qke.89.1612556917322; Fri, 05 Feb 2021 12:28:37 -0800 (PST) MIME-Version: 1.0 References: <97F5C09F-7AE3-4763-AD32-BFEA25101CE5@me.com> <014891C8-7B1F-4908-9495-2ED1A5FAABCF@me.com> In-Reply-To: From: Warner Losh Date: Fri, 5 Feb 2021 13:28:26 -0700 Message-ID: Subject: Re: git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev To: Jessica Clarke Cc: Toomas Soome , Toomas Soome , src-committers , "" , dev-commits-src-branches@freebsd.org X-Rspamd-Queue-Id: 4DXRny1HSmz4Vn2 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:28:38 -0000 On Fri, Feb 5, 2021 at 1:25 PM Jessica Clarke wrote: > On 5 Feb 2021, at 20:21, Warner Losh wrote: > > > > On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome wrote: > >> >> >> On 5. Feb 2021, at 21:43, Warner Losh wrote: >> >> >> >> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome wrote: >> >>> >>> >>> On 5. Feb 2021, at 18:44, Warner Losh wrote: >>> >>> >>> >>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome wrote: >>> >>>> >>>> >>>> On 5. Feb 2021, at 01:56, Warner Losh wrote: >>>> >>>> =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... >>>> >>>> Warner >>>> >>>> >>>> Reason is in PR. There is someone with the system without ConOut but >>>> ConOutDev is set. Instead of falling back to arbitrary device (which i= n >>>> this case was totally wrong choice), we can try the possible devices l= ist. >>>> We do not change the ConOut parsing. >>>> >>> >>> We could have the same effect defaulting to Video. This bug should have >>> been discussed / reviewed before it was committed. >>> >>> >>> How is is different from defaulting to serial, it is just as bad? we ca= n >>> not guess there, thats why we do have ConOutDev list. >>> >>> >>> >>> If it would appear, there are systems with unusable devices listed in >>>> ConOutDev, then we need to think how to handle such case. >>>> >>> >>> 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. >>> >>> >>> We *should not* fall back on arbitrary devices when there is source for >>> alternate options. And that option is from specification: >>> >>> "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 s= et >>> dynamically on every boot. ConIn, ConOut, and ErrOut are always proper >>> subsets of ConInDev, ConOutDev, and ErrOutDev.*=E2=80=9D* >>> >> >> 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. >> >> >> 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 par= t >> we are going to follow and what not. >> > > 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 trivi= al > subsets (which are the empty set and, if not empty, the original set)? > Yes. I was confusing the two, but 'proper subset' doesn't make sense in the original standard wording since it's often the case that ConOut and ConOutDev are exactly the same. And there's a difference between ConOut being present, but empty (which would be a subset) and it being absent, imho, that puts us in 'what to do in non-standard-compliant' behavior of the BIOS... Warner