git: 0c839497c174 - stable/13 - loader.efi: There are systems without ConOut, also use ConOutDev

[Warner Losh]

On Fri, Feb 5, 2021 at 1:25 PM Jessica Clarke <jrtc27 at freebsd.org> wrote:

> On 5 Feb 2021, at 20:21, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Fri, Feb 5, 2021 at 1:09 PM Toomas Soome <tsoome at me.com> wrote:
>
>>
>>
>> On 5. Feb 2021, at 21:43, Warner Losh <imp at bsdimp.com> wrote:
>>
>>
>>
>> On Fri, Feb 5, 2021 at 10:24 AM Toomas Soome <tsoome at me.com> wrote:
>>
>>>
>>>
>>> On 5. Feb 2021, at 18:44, Warner Losh <imp at bsdimp.com> wrote:
>>>
>>>
>>>
>>> On Thu, Feb 4, 2021 at 11:38 PM Toomas Soome <tsoome at me.com> wrote:
>>>
>>>>
>>>>
>>>> On 5. Feb 2021, at 01:56, Warner Losh <imp at 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