> On 5 Feb 2021, at 20:21, Warner Losh <[email protected]> wrote: > > > > On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome <[email protected] > <mailto:[email protected]>> wrote: > > >> On 5. Feb 2021, at 21:43, Warner Losh <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On 5. Feb 2021, at 18:44, Warner Losh <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On 5. Feb 2021, at 01:56, Warner Losh <[email protected] >>>> <mailto:[email protected]>> 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)? Jess _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all To unsubscribe, send any mail to "[email protected]"
