RFC: Adding a hw.features[2] sysctl

[Nathan Lay]

Igor Mozolevsky wrote:
> On 14/01/2008, Daniel O'Connor <doconnor at gsoft.com.au> wrote:
>   
>> On Mon, 14 Jan 2008, Igor Mozolevsky wrote:
>>     
>>> On 13/01/2008, Peter Jeremy <peterjeremy at optushome.com.au> wrote:
>>>       
>>>> 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
>>>>         
>>> /dev/sndstat?
>>>       
>> A single handy counter example to the many many that are sysctls :)
>>
>>     
>>> If it's in /dev you can do neat tricks like ioctl-ing queries (like
>>> ioctl(/dev/cpuinfo, CINFOCTL_HAS_FEATURES, CINFO_SSE3|CINFO_SSSE3))
>>> instead of having *every* app parse the result of a sysctl; most of
>>> the time you'd only want to check for specific feature , it's much
>>> easier to do an ioctl that returns a boolean.
>>>       
>> Except you can't do that from a shell script.
>> (eg wrapper script to run optimised binaries)
>>     
>
> cat /dev/cpuinfo and parse away!
>
>
> Igor
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
>   
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.

Best Regards,
Nathan Lay