From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 16:45:31 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 2C24816A46E for ; Mon, 14 Jan 2008 16:45:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB4C13C455 for ; Mon, 14 Jan 2008 16:45:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JESRC-0007Mr-15 for freebsd-current@freebsd.org; Mon, 14 Jan 2008 16:45:26 +0000 Received: from www.creo.hu ([217.113.62.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jan 2008 16:45:26 +0000 Received: from csaba-ml by www.creo.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jan 2008 16:45:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Csaba Henk Date: Mon, 14 Jan 2008 16:45:15 +0000 (UTC) Lines: 45 Message-ID: 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-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: www.creo.hu User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news 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 16:45:31 -0000 On 2008-01-14, Igor Mozolevsky wrote: > On 14/01/2008, Csaba Henk wrote: >> Hm, I just fail to see the how the ioctl interface is different from >> the sysctl interface in terms of semantic capabilites. > > You need to *define* the output of a sysctl, you don't have to produce > any output in ioctl, just a boolean reply or a mask that can be > processed with #define macros... I honestly don't see how all of that > can be abstracted away in a MIB given that there is a number of > Intel|AMD|Whoever feature/feature1, who knows when feature2 will be > needed... 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... > > 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. Csaba