From owner-dev-commits-src-branches@freebsd.org Fri Feb 5 19:44:11 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 AD3705286A9 for ; Fri, 5 Feb 2021 19:44:11 +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 4DXQpf61Sgz4Rd9 for ; Fri, 5 Feb 2021 19:44:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id a7so8064567qkb.13 for ; Fri, 05 Feb 2021 11:44:10 -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=CXdXexmwjSVSsGxsH8Sl8jXqJi9f4fMaUazAdgHRWrk=; b=WFVyXTOLGxpUJ43KSqUmYcZ2Fk26aJLPRjrWgqPtmeWm6ne1ldKkg6bhNDXQKvmTtS 6wZkGR6pJpvS1ebIbWaYgq9hy53DFr9CWFrp+6l/izAuy2cG3wKtyFv30dVQ9lnyxB0M ZZwx2CjzWhmJIKHHftV0XpV1zK3D6/dSQ46SzF64rHloR9Xz1t3oOdyvekihJLtDXuSN 7noCk6hFibvZ4SPwr0k/ocnTSkVAmDaC1nGwmDBQgYAeBWfwcL+1EFGEYZYumjurwCQV mn8veMV3FXo8jLgBesaH3lNkqgmANvHf8t5pLahXabHkDyE71gIPck8T08aKkFbvgUm4 oNzQ== 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=CXdXexmwjSVSsGxsH8Sl8jXqJi9f4fMaUazAdgHRWrk=; b=pZLPdyIdd+fWVMuSpY92tTkPEMWnKaDa7UZs6ZiJ+QGtQnd34CXrFqlAQDqPhoyL9z EfjWSriRNdAPe3BUABpYjDOevwjjSOCsSQVChMOZ1fmZRWF/87XkjlnhEpk91TVmSylR H8pI32wuXuH5z0hi9iHs9Ej7GkRXEbF5BnEtmgSA3nq945XMcCn0eV0ERacG8skN4SOC NKBLgnE3tCheJW2yV40DynYXkWI+PLNprUkmHh1YE6aQrZmEzITgNefK1T5SbPcfc1Ev tf9b1C4TjQg8ZCn8zoeidWWSVryhQxc1+7T+4SVbmTaKA6/YqwIGNe2l68xF9o0C0jEg uLFg== X-Gm-Message-State: AOAM531j3AUnEkLttZD+FkWZQ+IRHeYieKclv7+38tUeNAtkv+TDU5Jg pdhFcrxYXe5zRO48C935nyNllOyht6ClC7y6eYtp6w== X-Google-Smtp-Source: ABdhPJzQRLpmj7Rvr85T+kJaihERtYVIvhOJ/+ZxGm/h2cFKC29ONLlfItUijPW020dIIKjXVSqc1LQVnnYnRD0Qz9Q= X-Received: by 2002:a37:a34f:: with SMTP id m76mr5862632qke.89.1612554249518; Fri, 05 Feb 2021 11:44:09 -0800 (PST) MIME-Version: 1.0 References: <97F5C09F-7AE3-4763-AD32-BFEA25101CE5@me.com> In-Reply-To: <97F5C09F-7AE3-4763-AD32-BFEA25101CE5@me.com> From: Warner Losh Date: Fri, 5 Feb 2021 12:43:58 -0700 Message-ID: Subject: Re: git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev To: Toomas Soome Cc: Toomas Soome , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-branches@freebsd.org X-Rspamd-Queue-Id: 4DXQpf61Sgz4Rd9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=WFVyXTOL; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-branches@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::72d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72d:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[me.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::72d:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[dev-commits-src-branches]; RCVD_COUNT_TWO(0.00)[2] 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 19:44:11 -0000 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 in >> this case was totally wrong choice), we can try the possible devices lis= t. >> 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 can > 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_DEV= ICE_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. ConI= n, > 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. > UEFI Spec 2.8A, Page 82. > > There may or may not be Video (or Serial) device listed. If not, there ar= e > good chance we will be in trouble because the firmware internals may not = be > set up properly and we can just as well end up in hung system. > For x86, there's almost always Video. For !x86 it gets more troublesome. The kernel shouldn't hang when we give it the wrong console because if the device isn't there, it won't cninit won't work. > Please seek more review is the point I'd hoped to make in the private > email. This could easily have been reviewed. There was no urgent rush tha= t > required it to go in w/o review or even discussion. > > > However, you didn't answer my question: Why the instant MFC? There's a 3 > day minimum for changes in head... And there's nothing so urgent that > requires a short-circuit. > > Warner > > > > Because the issues is reported on 13. well, I guess You are right there, > could have waited a bit more. > Right. Exactly my point.... Warner > thanks, > toomas > > > > > > >> Thanks, >> Toomas >> >> On Thu, Feb 4, 2021, 2:34 PM Toomas Soome wrote: >> >>> The branch stable/13 has been updated by tsoome: >>> >>> URL: >>> https://cgit.FreeBSD.org/src/commit/?id=3D0c839497c174e961fc71f7d3329d0= 5b10ec5525b >>> >>> >>> commit 0c839497c174e961fc71f7d3329d05b10ec5525b >>> Author: Toomas Soome >>> AuthorDate: 2021-02-04 20:49:02 +0000 >>> Commit: Toomas Soome >>> CommitDate: 2021-02-04 21:33:15 +0000 >>> >>> loader.efi: There are systems without ConOut, also use ConOutDev >>> >>> Conout does contian the default output device name. >>> ConOutDev does contain all possible output device names, so we can >>> use it as fallback, when there is no ConOut. >>> >>> PR: 253253 >>> >>> (cherry picked from commit 2bd4ff2d8911009283e4e615ca4aad35a845f48b= ) >>> --- >>> stand/efi/loader/main.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/stand/efi/loader/main.c b/stand/efi/loader/main.c >>> index ca41cd4a2610..32b278950745 100644 >>> --- a/stand/efi/loader/main.c >>> +++ b/stand/efi/loader/main.c >>> @@ -735,6 +735,8 @@ parse_uefi_con_out(void) >>> how =3D 0; >>> sz =3D sizeof(buf); >>> rv =3D efi_global_getenv("ConOut", buf, &sz); >>> + if (rv !=3D EFI_SUCCESS) >>> + rv =3D efi_global_getenv("ConOutDev", buf, &sz); >>> if (rv !=3D EFI_SUCCESS) { >>> /* If we don't have any ConOut default to serial */ >>> how =3D RB_SERIAL; >> >> >