RFC: Adding a hw.features[2] sysctl

Igor Mozolevsky igor at hybrid-lab.co.uk
Mon Jan 14 07:47:30 PST 2008

On 14/01/2008, Csaba Henk <csaba-ml at creo.hu> wrote:
> On 2008-01-14, Igor Mozolevsky <igor at hybrid-lab.co.uk> wrote:
> > On 14/01/2008, Nathan Lay <nslay at comcast.net> wrote:
> >
> >>  cat'ing /dev/cpuinfo sounds reminiscent to Linux /proc.
> >
> > No it doesn't - it's a perfectly fine Unix way of doing things... The
> > purpose of /dev is to provide an interface to the devices on the
> > machine, (query-capable-)CPU is a device... Having /proc as an
> > interface to the kernel on the other hand...
> 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

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?


More information about the freebsd-current mailing list