From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 18:08:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542C816A418 for ; Mon, 14 Jan 2008 18:08:58 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id A10CC13C45A for ; Mon, 14 Jan 2008 18:08:57 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1303697uge.37 for ; Mon, 14 Jan 2008 10:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XgZXOvylzwsADOxOnGZI2JjUjAq7BLOIpf8bU0dXowE=; b=Zc5hKAXCwf+cAOxqipCsYdg2c0sORpINQUt9vgfCSlHpQkkFCzgFj0+l4nZlMCoPTVrUjtjri28RhX6oRIxzLk5vvMFtbt5BLeWUAGWD0Zny3pT4USbR+cog47mG0pFE4Sr2UcfR0hJOqoRy08O0qSHVN9sCad0+fW+dsEO9Zho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Aft7PuVOWcD30cUV9aT6hhB5L/ZWyXRitkwQcgduGXql/epuHOC9DhUFHvz2qJurvHiFlo9F9HKpkwrxr8sx+fSq2Ni4CXqzFOdzaX2zDHYZTUDOPXNTN6t4DLHDq3Hu2aq3A5+2szYiuj9kNNSIw8WYmTT40Li6X17GcSsbo/Y= Received: by 10.67.115.19 with SMTP id s19mr3888155ugm.70.1200334136159; Mon, 14 Jan 2008 10:08:56 -0800 (PST) Received: by 10.66.248.11 with HTTP; Mon, 14 Jan 2008 10:08:56 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 18:08:56 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Nathan Lay" In-Reply-To: <478B9D5C.4080101@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1200197787.67286.13.camel@shumai.marcuscom.com> <20080113182457.GN929@server.vk2pj.dyndns.org> <200801141254.20400.doconnor@gsoft.com.au> <478AE741.1000105@comcast.net> <478B9D5C.4080101@comcast.net> X-Google-Sender-Auth: 417accc42f73271a Cc: Kostik Belousov , freebsd-current@freebsd.org, Joe Marcus Clarke , Peter Jeremy 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 18:08:58 -0000 On 14/01/2008, Nathan Lay wrote: > > " > > 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). 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