RFC: Adding a hw.features[2] sysctl

Peter Jeremy peterjeremy at optushome.com.au
Sun Jan 13 10:25:05 PST 2008


On Sun, Jan 13, 2008 at 08:44:50AM +0200, Kostik Belousov wrote:
>On Sat, Jan 12, 2008 at 11:16:27PM -0500, Joe Marcus Clarke wrote:
>> I find it would be useful to have the list of CPU features available via
>> a sysctl.  Currently, he only ways to get this information are to have
>> linprocfs mounted, or parse dmesg.boot (if it exists).  Attached are
>Not quite true, since the raw CPU capabilities are accessible using
>the cpuid instruction, both to the kernel- and user-mode.

>> patches to add hw.features and hw.features2 sysctls for i386 and amd64
>> (where a list of CPU features is applicable).  The results are identical
>> to the Features and Features2 strings from dmesg:
>> 
>> hw.features2: 0x41d<SSE3,RSVD2,MON,DS_CPL,CNXT-ID>
>> hw.features:
>> 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>
>The only part that I do not fully agree is to dedicate 1Kb of the kernel
>memory to the strings that could be reconstructed in the usermode and
>are relatively rare used.

All the required strings are already part of identcpu.c so the only
overhead would be either a ~200 byte chunk of KVA to store a copy of
the identcpu output as a SYSCTL_STRING or a SYSCTL_PROC wrapper
around the relevant parts of identcpu.c

>I would suggest either export only bitmask of the cpu features and do
>the formatting in the sysctl(8),

A userland program could perform the cpuid functions itself just as
easily as extracting the information from a sysctl.

>The first option could be preferable, since kernel might disable some
>features, that is not reflected in the output of cpuid instruction.
>Example of this would be identcpu.c, line 860 (HTT on AMD).

This depends whether you want to know what features are available on
the CPU or what features are available in the currently running kernel.
In Peter's case, there was a requirement to know the CPU capabilities.
OTOH, something like mplayer wants to know what features it can use
whilst it's currently executing.

On Sun, Jan 13, 2008 at 12:21:02PM +0000, Igor Mozolevsky wrote:
>Would /dev/cpuinfo not be more appropriate for this?

IMHO, no.  Virtually all similar FreeBSD information is exported via
sysctl and this sort of information fits neatly into the existing
MIB tree as either dev.cpu.N.features or hw.cpu.features

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080113/9cae4dc5/attachment.pgp


More information about the freebsd-current mailing list