From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 17:03:44 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 9094116A420 for ; Mon, 14 Jan 2008 17:03:44 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id E5F8E13C44B for ; Mon, 14 Jan 2008 17:03:43 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1293703uge.37 for ; Mon, 14 Jan 2008 09:03:42 -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=7CbGmq6Kc0ZV3i7gZPPagH1P3bWjixWMsQKVOdMLFss=; b=BmUBFWQraDAqilR2JPWq5CD7Kfj7J8XWVrWT48EODAAMoh08wsk/YdqAt/a9JBpB1ebLgOS8N7fYVp18cmfnD563W7aDucXf5uRpVRHQQvM/KR81Mfpk6+u7FXr0IhFZMaVZi7Km7nBXJRBa5Uy3UlfCvQTEbq1108t2Phwqga0= 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=Qu08mwgb1NyH32ZINqsnC32ABWcG4oFEzOKrvzqho7m6hi0f/vA0aybs6QnHfLRyjTOFsdi05QXFqCDJIReF1zp0Jlt0DnPeWs/5r7b61M6ozo8Mb/DuE/eaFLDhdHHWSXjd4v4Vrbu7I1YTrintv0ctsiOKZ1417wh6t/hPkhE= Received: by 10.66.243.13 with SMTP id q13mr3705711ugh.59.1200330222562; Mon, 14 Jan 2008 09:03:42 -0800 (PST) Received: by 10.66.248.11 with HTTP; Mon, 14 Jan 2008 09:03:42 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 17:03:42 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Csaba Henk" In-Reply-To: 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> X-Google-Sender-Auth: 7ed55996c5a4e50e Cc: freebsd-current@freebsd.org 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:03:44 -0000 On 14/01/2008, Csaba Henk wrote: > I don't pretend that I'm an expert of the topic discussed, I just don't > see any essential difference (in terms of convenience or expressive > power) between these: > > ################################################ > /* your code sample */ > cpu_features_t mask; > > fd = open( "/dev/cpuinfo", O_RDONLY ); > ioctl( fd, SIOCGCPUFEATURES, (caddr_t)&mask ); > close( fd ); > ################################################ > > ################################################ > cpu_features_t mask; > size_t len = sizeof(mask); > > sysctlbyname("hw.features", &mask, &len, NULL, 0); > ################################################ > > (and then the macro based processing of the mask > can be done exactly the same way). > > > If it can be done reasonably in a MIB, I won't say a word, but > > nobody's proposed any data representation for a (or a number of) > > MIB(s) yet... I didn't ask for user-land implementation detail, I was asking how you'd represent all of this: " Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 " using MIBs?.. Would you need ...features=0x178bfbff ...features2=0x1 ...amd.features=0xe2500800 ...amd.features20x3; or ...features="1=0x178bfbff 2=0x1 AMD1=0xe2500800 AMD2=0x3", both of which would make life on the user-land side much more difficult than a few ioctls that hide all the details away, IMO. > > What's the overhead of sysctl vs ioctl? > > Well, looking at the above code examples, the ioctl based implementation > costs three syscalls, the sysctl based one costs only two. syscall overhead != system overhead! I genuinely don't know (and don't have the time to work out) the actual overhead of a sysctl vs ioctl, so if someone knows please let me know :-) Igor