bin/52414: cpuctl(8)/cpuctl(4) shortcomings

[paul%whooppee.com@localhost]

>Number:         52414
>Category:       bin
>Synopsis:       cpuctl(8)/cpuctl(4) shortcomings
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 17 11:10:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 8.99.1
>Organization:
+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 8.99.1 NetBSD 8.99.1 (SPEEDY 2017-06-28 12:54:24 UTC) #0: Wed Jun 28 17:26:09 UTC 2017 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
(I've marked this as a doc-bug even though there are suggestions for
improving the code itself.  Please feel free to recategorize if needed.

Current the cpuctl(8) man-page is very amd centric for the microcode update
function.  It specifies an amd-specific default filename and the FILES
section lists only the /libdata/firmware/x86/amd/ directory.  It also
provides a download URL for the microcode files only for amd!

It might also be nice for the code to be changed to detect Intel-vs-AMD
characteristic and apply different defaults.  (For Intel, the default
file could be /libdata/firmware/x86/intel/FF-MM-SS since the Intel files
as currently distributed are named for the CPU's Family-Model-Stepping.)

It certainly doesn't make sense to have an amd-specific default filename
for non-amd processors.  Preferably the code will validate that the file
used is appropriate for the processor in question.  Which brings up yet
another shortcoming of the current man-page and/or code:  are there any
reasonable DIAGNOSTICS issued if the microcode file is not appropriate
for the processor being updated?  And/or is there any iBUG/CAVEAT needed
to warn users that applying an incorrect microcode file might render the
processor unuseable?

Finally, the cpuctl(8) utility apparently uses a pseudo-device cpuctl(4).
Yet there is no man-page for cpuctl(4), so there exists no documentation
on the mechanism for retrieving or updating the information.  Since the
cpuctl(4) pseudo-device is included in all kernels by default, it only
seems reasonable to document the device interface.

	
>How-To-Repeat:
	
>Fix:
	

>Unformatted: