From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 04:23: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 DBE2216A420 for ; Mon, 14 Jan 2008 04:23:02 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8D48013C469 for ; Mon, 14 Jan 2008 04:23:02 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id crc21Y00W17dt5G0502W00; Mon, 14 Jan 2008 04:12:01 +0000 Received: from ANTENNA.LOCAL ([68.35.224.189]) by OMTA13.westchester.pa.mail.comcast.net with comcast id csBi1Y00D45o48c3Z00000; Mon, 14 Jan 2008 04:11:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=BZmrEeO8dF8A:10 a=1r4_pJJx8qSmTN7QIIAA:9 a=Eh7T4eD_ag5WhJC2OnpDpzLrI_0A:4 a=si9q_4b84H0A:10 a=a24e7YDjOykA:10 Message-ID: <478AE0B0.6000505@comcast.net> Date: Sun, 13 Jan 2008 23:10: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> <20080113064450.GW57756@deviant.kiev.zoral.com.ua> <20080113182457.GN929@server.vk2pj.dyndns.org> <478AC1F0.10500@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Peter Jeremy , 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: Mon, 14 Jan 2008 04:23:02 -0000 Igor Mozolevsky wrote: > On 14/01/2008, Nathan Lay wrote: > >> Igor Mozolevsky wrote: >> >>> On 13/01/2008, Peter Jeremy wrote: >>> >>> >>> >>>> 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 >>>> >>>> >>> /dev/sndstat? >>> >>> If it's in /dev you can do neat tricks like ioctl-ing queries (like >>> ioctl(/dev/cpuinfo, CINFOCTL_HAS_FEATURES, CINFO_SSE3|CINFO_SSSE3)) >>> instead of having *every* app parse the result of a sysctl; most of >>> the time you'd only want to check for specific feature , it's much >>> easier to do an ioctl that returns a boolean. >>> >> Or perhaps, create an ioctl that returns a bitmask of all available CPU >> features. This way, only one ioctl() call is necessary and allows >> programs to query any and all features in an inexpensive way. Calling >> ioctl() for each feature query is comparably more expensive. >> > > You won't you'd OR all of the features you want to check; but yes, > having a param that returns the whole lot would also be great, as well > as the driver returning human-readable representation if it was open > for writing... The idea is to allow the flexibility, so that the > programmers/users are free to choose what suits them, and not being > forced into having to do only one thing. :-) > > > Igor > > Yes, but suppose a program needs to make these queries more than once...for whatever reason? For example, a closed source math code might need to figure out which version of a function to execute at run time based on available CPU features. It will likely have to issue these ioctl() calls more than once (even with OR). For example: if ( ioctl( fd, CINFOCTL_HAS_FEATURES, ) ) LU_factor_( ... ); else if ( ioctl( fd, CINFOCTL_HAS_FEATURES, ) ) LU_factor_( ... ); etc... If the ioctl returns a bitmask with all available CPU features, then only one ioctl() call is needed. The features can easily be queried from the bitmask. One can make it even easier and more readable by making a macro like FD_ISSET to do such queries. A rough example: cpu_features_t mask; fd = open( "/dev/cpuinfo", O_RDONLY ); ioctl( fd, SIOCGCPUFEATURES, (caddr_t)&mask ); close( fd ); if ( CPU_HAS_FEATURES(mask, CPU_SSE|CPU_SSE2) ) { ... } ... if ( CPU_HAS_FEATURES(mask, ... ) ) ... Or something like that The bitmask solution also makes it reasonably easy to generate a human readable string. Just go through each bit. No ioctl needed for that either. A simple program can be written to analyze the bitmask and output human readable version of the features. Best Regards, Nathan Lay