Date: Fri, 5 Feb 2021 13:28:26 -0700 From: Warner Losh <imp@bsdimp.com> To: Jessica Clarke <jrtc27@freebsd.org> Cc: Toomas Soome <tsoome@me.com>, Toomas Soome <tsoome@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-branches@freebsd.org Subject: Re: git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev Message-ID: <CANCZdfo6eSpubbgpyaNzKKiyNoxsde=4JCN7PdfSDvbZJ5me8w@mail.gmail.com> In-Reply-To: <E51A6426-4C54-45DB-80DE-91EE366B3469@freebsd.org> References: <CANCZdfqXU7Syo4wvxJ17Gt%2B0E2Kw8yOU_nrTNA%2Beu=z-ZwTKow@mail.gmail.com> <CF59D855-228A-4BC1-AC4B-0C54417EF3BF@me.com> <CANCZdfrdpMXTxJbzY6w2NE_DtwZ1eBuMm%2B1rr6d0a22R2QKaCQ@mail.gmail.com> <97F5C09F-7AE3-4763-AD32-BFEA25101CE5@me.com> <CANCZdfpf6KAyPCnxJnxPAg2K4POK7okkp1m3O28VvAcrK1tzag@mail.gmail.com> <014891C8-7B1F-4908-9495-2ED1A5FAABCF@me.com> <CANCZdfo-pRUQhw_7=MN6VPOcsgvRoP47PUC44yjbZbzopdtJSw@mail.gmail.com> <E51A6426-4C54-45DB-80DE-91EE366B3469@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 5, 2021 at 1:25 PM Jessica Clarke <jrtc27@freebsd.org> wrote: > On 5 Feb 2021, at 20:21, Warner Losh <imp@bsdimp.com> wrote: > > > > On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome <tsoome@me.com> wrote: > >> >> >> On 5. Feb 2021, at 21:43, Warner Losh <imp@bsdimp.com> wrote: >> >> >> >> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome <tsoome@me.com> wrote: >> >>> >>> >>> On 5. Feb 2021, at 18:44, Warner Losh <imp@bsdimp.com> wrote: >>> >>> >>> >>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome <tsoome@me.com> wrote: >>> >>>> >>>> >>>> On 5. Feb 2021, at 01:56, Warner Losh <imp@bsdimp.com> wrote: >>>> >>>> >>>> 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 list. >>>> 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_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.*”* >>> >> >> 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 part >> 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 trivial > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo6eSpubbgpyaNzKKiyNoxsde=4JCN7PdfSDvbZJ5me8w>