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

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