From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 18:25:05 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 0566016A41B for ; Sun, 13 Jan 2008 18:25:05 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 88E3613C469 for ; Sun, 13 Jan 2008 18:25:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m0DIOxd0010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 05:25:00 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m0DIOxNX025798; Mon, 14 Jan 2008 05:24:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m0DIOwim025797; Mon, 14 Jan 2008 05:24:58 +1100 (EST) (envelope-from peter) Date: Mon, 14 Jan 2008 05:24:58 +1100 From: Peter Jeremy To: Kostik Belousov , Igor Mozolevsky Message-ID: <20080113182457.GN929@server.vk2pj.dyndns.org> References: <1200197787.67286.13.camel@shumai.marcuscom.com> <20080113064450.GW57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20080113064450.GW57756@deviant.kiev.zoral.com.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joe Marcus Clarke , current 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: Sun, 13 Jan 2008 18:25:05 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2008 at 08:44:50AM +0200, Kostik Belousov wrote: >On Sat, Jan 12, 2008 at 11:16:27PM -0500, Joe Marcus Clarke wrote: >> I find it would be useful to have the list of CPU features available via >> a sysctl. Currently, he only ways to get this information are to have >> linprocfs mounted, or parse dmesg.boot (if it exists). Attached are >Not quite true, since the raw CPU capabilities are accessible using >the cpuid instruction, both to the kernel- and user-mode. >> patches to add hw.features and hw.features2 sysctls for i386 and amd64 >> (where a list of CPU features is applicable). The results are identical >> to the Features and Features2 strings from dmesg: >>=20 >> hw.features2: 0x41d >> hw.features: >> 0xbfebfbff > >The only part that I do not fully agree is to dedicate 1Kb of the kernel >memory to the strings that could be reconstructed in the usermode and >are relatively rare used. All the required strings are already part of identcpu.c so the only overhead would be either a ~200 byte chunk of KVA to store a copy of the identcpu output as a SYSCTL_STRING or a SYSCTL_PROC wrapper around the relevant parts of identcpu.c >I would suggest either export only bitmask of the cpu features and do >the formatting in the sysctl(8), A userland program could perform the cpuid functions itself just as easily as extracting the information from a sysctl. >The first option could be preferable, since kernel might disable some >features, that is not reflected in the output of cpuid instruction. >Example of this would be identcpu.c, line 860 (HTT on AMD). This depends whether you want to know what features are available on the CPU or what features are available in the currently running kernel. In Peter's case, there was a requirement to know the CPU capabilities. OTOH, something like mplayer wants to know what features it can use whilst it's currently executing. On Sun, Jan 13, 2008 at 12:21:02PM +0000, Igor Mozolevsky wrote: >Would /dev/cpuinfo not be more appropriate for this? IMHO, no. Virtually all similar FreeBSD information is exported via sysctl and this sort of information fits neatly into the existing MIB tree as either dev.cpu.N.features or hw.cpu.features --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHild5/opHv/APuIcRAtDwAKCB3iqORvoRpwYl1z+k0lRSYaWX/gCePV7P +VBe/2awkA6qrXvS3eYURR8= =O87V -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--