Re: git: d12bc36e7698 - main - cpu-microcode-intel: Add knobs for RC RUN_DEPENDS and split files

On Tue, 2023-11-14 at 18:11, Marius Strobl <marius@freebsd.org> wrote:

> On Mon, Nov 13, 2023 at 12:35:33PM -0400, Joseph Mingrone wrote:
>> On Thu, 2023-11-09 at 20:25, Marius Strobl <marius@FreeBSD.org> wrote:

>> > The branch main has been updated by marius:

>> > URL: https://cgit.FreeBSD.org/ports/commit/?id=d12bc36e7698f3737de1ac228bd49eab10cf1bb0

>> > commit d12bc36e7698f3737de1ac228bd49eab10cf1bb0
>> > Author:     Marius Strobl <marius@FreeBSD.org>
>> > AuthorDate: 2023-11-09 20:20:53 +0000
>> > Commit:     Marius Strobl <marius@FreeBSD.org>
>> > CommitDate: 2023-11-09 20:20:53 +0000

>> >     cpu-microcode-intel: Add knobs for RC RUN_DEPENDS and split files

>> >     Split UCODE files as well as dependency on sysutils/cpu-microcode-rc
>> >     are only required for use with cpucontrol(8) and update method two
>> >     respectively. The first method needs neither so we can spare a few
>> >     MiB and a superfluous port.
>> >     Given that the automatic update method one is superior, the RC knob
>> >     should be deprecated and removed eventually. At that point, split
>> >     UCODE files still will be useful for developers and if users want
>> >     to update the microcode without a reboot (but otherwise rely on the
>> >     loader for automatic updates, i. e. method one).

>> For the reasons you described, I proposed removing the RC script for the
>> Intel CPU microcode updates [1].  However, there was a reasonable
>> argument for keeping it.  As you say, users may still want to update
>> their Intel CPU microcode this way because updates can be applied on a
>> running system without requiring downtime for a reboot.

>> With your commit, I think we have a good compromise.  Users who really
>> want to save a bit of space and have one fewer port installed can turn
>> off these two knobs.  Maybe we could make that the default.

>> Joe

>> [1] See the comments in https://reviews.freebsd.org/D32349 for details.

> Hi Joe,

> it's probably a matter of taste but when it does come to something
> like updating UCODE on a running - likely critical as otherwise I'd
> simply reboot with the new firmware in place - system, I typically
> feel uneasy and want to know exactly what's going to be done. For
> me, this translates to - as mentioned earlier - using cpucontrol(8)
> directly, i. e. issuing:
> # echo /dev/cpuctl* | xargs -n 1 cpucontrol -u
> instead of a 77 lines of code for microcode_update on top of 175
> lines of script for service(8). IMO that's also not particularly
> more cryptic of harder to remember than:
> # service microcode_update onestart

> In any case, as previously stated there's no need to employ the
> RC script for manual updates either and least as far as I'm
> concerned, running cpucontrol(8) directly instead is preferable.
> Thus, I propose to at least switch the default. But I leave that
> decision up to you.

> Marius

Hi Marius,

Those are valid points.  Let's leave this thread open for about a month
and if no one objects to turning those knobs off by default, I'll make
the change.

Thanks,

Joe