Re: conf/files.xen changes proposal

[Greg Troxel <gdt%ir.bbn.com@localhost>]

rudolf <netbsd%eq.cz@localhost> writes:

> Greg Troxel wrote:
>> rudolf <netbsd%eq.cz@localhost> writes:
>>> I admit that I am not sure if this proposed change is right. I
>>> contacted the responsible person some time ago and got no answer.
>>>
>>> If I build the XEN_DOM0 kernel without CPU_UCODE without this proposed
>>> change, then the build fails. If I build unchanged XEN_DOM0 kernel
>>> (with CPU_UCODE) with this proposed change, the kernel build finishes
>>> without a hiccup (CVS tag netbsd-6-1-RELEASE).
>>
>> And does it actually work and pass regression tests?
>
> I don't know.

So unless the change is known to work, it shouldn't be considered for
being applied.  It's clear that you have found a bug, but much less
clear what the fix is.

>> The intent of the
>> original lines seem clear: xen_ucode and cpu_ucode_amd are required in a
>> dom0, even if the cpu_ucode option is not given.  When was this
>> committed?  What did the commit message say?
>
> Fri Jan 13 16:05:16 UTC 2012,
>
> ``Support CPU microcode loading via cpuctl(8).
> Implemented and enabled via CPU_UCODE kernel config option
> for x86 and Xen Dom0.
> Tested on different AMD machines with different
> CPU families.
>
> ok wiz@ for the manpages
> ok releng@
> ok core@ via releng@''
>
> http://mail-index.netbsd.org/source-changes/2012/01/13/msg030603.html

So there is support for loading microcode.  This makes sense in a dom0,
as Jean-Yves points out.

Often the right solution is more careful ifdefing.  Your proposed fix
may be right.

But, without an explanation of why you think it's right (other than that
you tried it without understanding the code and it built, but it's not
known to run), there's no basis for confidence.