From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 17:37:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528C816A41A for ; Mon, 14 Jan 2008 17:37:02 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id C929A13C457 for ; Mon, 14 Jan 2008 17:37:01 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id d4UQ1Y00T1HzFnQ050A700; Mon, 14 Jan 2008 17:37:01 +0000 Received: from ANTENNA.LOCAL ([68.35.224.189]) by OMTA14.westchester.pa.mail.comcast.net with comcast id d5ce1Y00945o48c3a00000; Mon, 14 Jan 2008 17:36:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=BZmrEeO8dF8A:10 a=AWZsz0D3HEaANAFFC6IA:9 a=abw7UR8LeD_HYzdCDrsA:7 a=4eolpm2fWpqtU4OE71uOfqjI6eEA:4 a=si9q_4b84H0A:10 a=a24e7YDjOykA:10 Message-ID: <478B9D5C.4080101@comcast.net> Date: Mon, 14 Jan 2008 12:35:24 -0500 From: Nathan Lay User-Agent: Thunderbird 2.0.0.9 (X11/20071230) MIME-Version: 1.0 To: Igor Mozolevsky References: <1200197787.67286.13.camel@shumai.marcuscom.com> <20080113182457.GN929@server.vk2pj.dyndns.org> <200801141254.20400.doconnor@gsoft.com.au> <478AE741.1000105@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current , freebsd-current@freebsd.org, Joe Marcus Clarke , Peter Jeremy , Kostik Belousov Subject: Re: RFC: Adding a hw.features[2] sysctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 17:37:02 -0000 Igor Mozolevsky wrote: > On 14/01/2008, Nathan Lay wrote: > > >> 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. >> > > So how would you MIB these: > > " > CPU: Dual Core AMD Opteron(tm) Processor 280 (2411.12-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > Features=0x178bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > 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). Best Regards, Nathan Lay