RFC: Adding a hw.features[2] sysctl

[Csaba Henk]

On 2008-01-14, Igor Mozolevsky <igor at hybrid-lab.co.uk> wrote:
> On 14/01/2008, Csaba Henk <csaba-ml at creo.hu> wrote:
>> Hm, I just fail to see the how the ioctl interface is different from
>> the sysctl interface in terms of semantic capabilites.
>
> You need to *define* the output of a sysctl, you don't have to produce
> any output in ioctl, just a boolean reply or a mask that can be
> processed with #define macros... I honestly don't see how all of that
> can be abstracted away in a MIB given that there is a number of
> Intel|AMD|Whoever feature/feature1, who knows when feature2 will be
> needed...

I don't pretend that I'm an expert of the topic discussed, I just don't
see any essential difference (in terms of convenience or expressive
power) between these:

################################################
/* your code sample */
cpu_features_t mask;

fd = open( "/dev/cpuinfo", O_RDONLY );
ioctl( fd, SIOCGCPUFEATURES, (caddr_t)&mask );
close( fd );
################################################

################################################
cpu_features_t mask;
size_t len = sizeof(mask);

sysctlbyname("hw.features", &mask, &len, NULL, 0);
################################################

(and then the macro based processing of the mask
can be done exactly the same way).

> If it can be done reasonably in a MIB, I won't say a word, but
> nobody's proposed any data representation for a (or a number of)
> MIB(s) yet...
>
> What's the overhead of sysctl vs ioctl?

Well, looking at the above code examples, the ioctl based implementation
costs three syscalls, the sysctl based one costs only two.

Csaba