Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jan 2008 16:45:15 +0000 (UTC)
From:      Csaba Henk <csaba-ml@creo.hu>
To:        freebsd-current@freebsd.org
Subject:   Re: RFC: Adding a hw.features[2] sysctl
Message-ID:  <slrnfon4at.i6j.csaba-ml@beastie.creo.hu>
References:  <1200197787.67286.13.camel@shumai.marcuscom.com> <20080113182457.GN929@server.vk2pj.dyndns.org> <a2b6592c0801131721w25afae5bg3dcf6a90c1a3d2b7@mail.gmail.com> <200801141254.20400.doconnor@gsoft.com.au> <a2b6592c0801131838jcde3634le6087d2f784adcbc@mail.gmail.com> <478AE741.1000105@comcast.net> <a2b6592c0801140139v42bb6ab2s667ebceb9ba3ab16@mail.gmail.com> <slrnfomt3j.i6j.csaba-ml@beastie.creo.hu> <a2b6592c0801140747r2a7ec1e5q7cd858065399ae65@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2008-01-14, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote:
> On 14/01/2008, Csaba Henk <csaba-ml@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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnfon4at.i6j.csaba-ml>