Re: RFC: Adding a hw.features[2] sysctl

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
friendly.

> 
> >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[2] lines.  This shows the features that are available on the
CPU.

Thanks to everyone who has replied so far.  The comments have been
helpful.

Joe

> 
> 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
http://www.FreeBSD.org/gnome