RFC: Adding a hw.features[2] sysctl

Nathan Lay nslay at comcast.net
Sun Jan 13 20:40:02 PST 2008

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

More information about the freebsd-current mailing list