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

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