RFC: Adding a hw.features sysctl
Joe Marcus Clarke
marcus at FreeBSD.org
Sun Jan 13 19:08:01 PST 2008
On Mon, 2008-01-14 at 05:24 +1100, Peter Jeremy wrote:
> 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
Agreed, the memory footprint could be made much smaller than in my
patch. I think a string would be fine. I think a proc might be
overkill as this information will not change.
> >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.
It would be easy to export just the bitmask, and leave the parsing up to
the consumer. However, I think the strings would be more script
> >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.
I had thought of making the output identical what is seen in dmesg's
Features lines. This shows the features that are available on the
Thanks to everyone who has replied so far. The comments have been
> 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
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome at FreeBSD.org
FreeNode / #freebsd-gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080114/c28d60ab/attachment.pgp
More information about the freebsd-current