Date: Mon, 14 Jan 2008 18:08:56 +0000 From: "Igor Mozolevsky" <igor@hybrid-lab.co.uk> To: "Nathan Lay" <nslay@comcast.net> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org, Joe Marcus Clarke <marcus@freebsd.org>, Peter Jeremy <peterjeremy@optushome.com.au> Subject: Re: RFC: Adding a hw.features[2] sysctl Message-ID: <a2b6592c0801141008j40676299rf455abbad93a31d0@mail.gmail.com> In-Reply-To: <478B9D5C.4080101@comcast.net> 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> <a2b6592c0801140126t4565b582ob4e9d10a4cd98147@mail.gmail.com> <478B9D5C.4080101@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/01/2008, Nathan Lay <nslay@comcast.net> wrote:
> > "
> > CPU: Dual Core AMD Opteron(tm) Processor 280 (2411.12-MHz K8-class CPU)
> > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2
> > Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> > Features2=0x1<SSE3>
> > AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
> > AMD Features2=0x3<LAHF,CMP>
> > Cores per package: 2
> > "
> >
> > ? Would you need four separate MIBs? Have four separate bitmasks in
> > one MIB, what order in? Is there XXX Features3, what would happen
> > then?
> >
> >
> > Igor
> >
> >
> Make one contiguous bitmask that include all of them. That way the
> bitmask can sit in one sysctl MIB.
>
> For example:
>
> typedef uint8_t cpu_features_t[4*4]; /* 4 32 bit masks */
>
> #define CPU_HAS_FEATURE(mask,feature) ( (mask)[(feature) >> 3] &
> (1<<((feature) & 0x07)) )
>
> /* CPU features - reflect bit positions */
> #define CPU_I386_SSE 1
> #define CPU_I386_SSE2 2
> ...
> #define CPU_AMD64_ ...
> etc, etc...
>
> Something along these lines. This of course removes the elegant OR'd
> flags and you'd have to do something like
>
> cpu_features_t mask;
>
> sysctl( ... ); /* Get mask */
> if ( CPU_HAS_FEATURE(mask, CPU_I386_SSE) || CPU_HAS_FEATURE(mask,
> CPU_I386_SSE2) ) ) { ... }
>
> These bit positions could be reclaimed for use by other
> architectures...the programmer's code or makefile would have to check
> that the code is being compiled on the intended architecture, otherwise
> you might have unexpected results (e.g. CPU_I386_SSE might mean
> something else).
There'd have to be a lot more sanity checks at runtime, on top of the
checks in the makefile. It's all getting very nasty on the userland,
just like I imagined. I doubt I will persuade you guys about the
portability and abstraction of an ioctl, so just go ahead and code it
as a MIB. If people want to write BSD-specific code to take advantage
of it in the future they can deal with it there and then...
Igor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a2b6592c0801141008j40676299rf455abbad93a31d0>