From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 03:08:01 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 7455816A417 for ; Mon, 14 Jan 2008 03:08:01 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 490E513C468 for ; Mon, 14 Jan 2008 03:08:01 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m0E39RpT008833; Sun, 13 Jan 2008 22:09:27 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Peter Jeremy In-Reply-To: <20080113182457.GN929@server.vk2pj.dyndns.org> References: <1200197787.67286.13.camel@shumai.marcuscom.com> <20080113064450.GW57756@deviant.kiev.zoral.com.ua> <20080113182457.GN929@server.vk2pj.dyndns.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZiOdBNAAe01gkc+60Kxp" Organization: FreeBSD, Inc. Date: Sun, 13 Jan 2008 22:08:25 -0500 Message-Id: <1200280105.7836.16.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on creme-brulee.marcuscom.com Cc: Kostik Belousov , current , Igor Mozolevsky 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 03:08:01 -0000 --=-ZiOdBNAAe01gkc+60Kxp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-01-14 at 05:24 +1100, Peter Jeremy wrote: > 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 v= ia > >> 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. >=20 > >> patches to add hw.features and hw.features2 sysctls for i386 and amd64 > >> (where a list of CPU features is applicable). The results are identic= al > >> 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. >=20 > 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 Agreed, the memory footprint could be made much smaller than in my patch. I think a string would be fine. I think a proc might be overkill as this information will not change. >=20 > >I would suggest either export only bitmask of the cpu features and do > >the formatting in the sysctl(8), >=20 > A userland program could perform the cpuid functions itself just as > easily as extracting the information from a sysctl. It would be easy to export just the bitmask, and leave the parsing up to the consumer. However, I think the strings would be more script friendly. >=20 > >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). >=20 > 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. I had thought of making the output identical what is seen in dmesg's Features[2] lines. This shows the features that are available on the CPU. Thanks to everyone who has replied so far. The comments have been helpful. Joe >=20 > On Sun, Jan 13, 2008 at 12:21:02PM +0000, Igor Mozolevsky wrote: > >Would /dev/cpuinfo not be more appropriate for this? >=20 > 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 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-ZiOdBNAAe01gkc+60Kxp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHitIpb2iPiv4Uz4cRAvkuAJ9m7x2rOHq6Hz7yyA7IJachBNmfzgCffV4B wSV2xTy8ZLlmr8936ZCRat0= =mlXp -----END PGP SIGNATURE----- --=-ZiOdBNAAe01gkc+60Kxp--