This allows having a common function for reporting multiple enums with
the same code. Paramters can be adjusted to suite.
Designated initializers make the CTASSERT() worthless, removed.
ehem_freebsd_m5p.com on Sat, Sep 25, 2:08 AM.Authored by
This is an attempt at a combined function for handling of enum sysctls. Hopefully enums never end up out of range, but I could believe it happening therefore the bounds check.
Biggest issue in my mind is whether I've matched the organization of subr_param.c. Seems reasonable since I'm mostly overwriting the vm_guest sections with equivalents. Now the array of strings is alphabetized since that works with this type of initialization.
The helper looks surprisingly not bad. Could there be other uses for some existing sysctls? I am slightly worried that hardcoding e.g. u_int *value makes it less useful than possible.
Pretty sure signed/unsigned mismatches are presently standard in the FreeBSD kernel. There would be warnings all over the place if -Wsign-conversion and -Wsign-compare were enabled.
Unsigned was simpler for the test to be correct, even though enum is supposed to be signed. This isn't difficult to remedy if you want such done.
For wider use "last" would be replaced with "first" and "count". Then the range test becomes *params->value - params->first >= params->count. Ideally the names array has the "first" element as 0, unfortunately this means when initializing the first value has to be added/subtracted from every enum, which could be painful if the enum has enough values.
I was pondering the possibility, though I'm unsure how many sysctls are enums behind the scenes.
Since the vm_guest enum starts at 0, the example is highly redundant, but is useful as an example of how this can be used. ENXIO seems appropriate for the out of range case, but it should be documented (note: I make no claims of skill with man formatting, hopefully my emulation of the rest of formatting generates something appropriate).
I still think that single example is too early to abstract. I can think about e.g. kern.timecounter.hardware and machdep.idle as possible extensions. Differently from kern.vm_guest, they are writeable, and there is no simple list of values. If you can fit that into your framework, perhaps the feature become much more interesting.