RFC: Adding a hw.features[2] sysctl

Nathan Lay nslay at comcast.net
Mon Jan 14 09:37:02 PST 2008


Igor Mozolevsky wrote:
> On 14/01/2008, Nathan Lay <nslay at comcast.net> wrote:
>
>   
>> I have to agree with Daniel here.  ioctl is probably inappropriate.
>> sysctl is already intended for gathering or setting system information
>> by both programs and/or people.  cat'ing /dev/cpuinfo sounds reminiscent
>> to Linux /proc.
>>
>> sysctl() could fill a cpu features bitmask for programs.
>> sysctl dev.cpu.features (or something like that) could output those
>> features in human readable format.
>>     
>
> So how would you MIB these:
>
> "
> CPU: Dual Core AMD Opteron(tm) Processor 280 (2411.12-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
>   Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>   Features2=0x1<SSE3>
>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>   AMD Features2=0x3<LAHF,CMP>
>   Cores per package: 2
> "
>
> ? Would you need four separate MIBs? Have four separate bitmasks in
> one MIB, what order in? Is there XXX Features3, what would happen
> then?
>
>
> Igor
>
>   
Make one contiguous bitmask that include all of them.  That way the 
bitmask can sit in one sysctl MIB.

For example:

typedef uint8_t cpu_features_t[4*4]; /* 4 32 bit masks */

#define CPU_HAS_FEATURE(mask,feature) ( (mask)[(feature) >> 3] & 
(1<<((feature) & 0x07)) )

/* CPU features - reflect bit positions */
#define CPU_I386_SSE    1
#define CPU_I386_SSE2    2
...
#define CPU_AMD64_ ...
etc, etc...

Something along these lines.  This of course removes the elegant OR'd 
flags and you'd have to do something like

cpu_features_t mask;

sysctl( ... ); /* Get mask */
if ( CPU_HAS_FEATURE(mask, CPU_I386_SSE) || CPU_HAS_FEATURE(mask, 
CPU_I386_SSE2) ) ) { ... }

These bit positions could be reclaimed for use by other 
architectures...the programmer's code or makefile would have to check 
that the code is being compiled on the intended architecture, otherwise 
you might have unexpected results (e.g. CPU_I386_SSE might mean 
something else).

Best Regards,
Nathan Lay


More information about the freebsd-current mailing list