From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 21:01:54 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB4781065686 for ; Sun, 18 May 2008 21:01:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 31A5A8FC17 for ; Sun, 18 May 2008 21:01:53 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so751266nfh.33 for ; Sun, 18 May 2008 14:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=c71sap8NVnK5k5BIOan5bv9HRJFAPeaWBRzIpN/0Oas=; b=P04RV3Cr78fN6Eyq6RVeOE9+P2dzjvnrLkF2p0iCpzCoKJo+ar5L+s6M/zq+z8Fho3ePGKiLfl6poWdU+ZOLmhqxL4PJZgvf2Xc80EBO/gzi2I4u4oVs4oUC75MQHbXkANPxv3ZxbVovq5GfpSq4WtdsdyG8NXyzol0LDCy4RR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=st2bBVkLbWAUH5/desA7F8XfY9EJcoWZI4fOJp9HpJZs4R+rbhwGP6hy0bf6dIib/K20sqE2zTKu4cUScoM4QipCtGPS8H3UfLQBEmO7ZZsUgdeh0cgScdDJZ8LoPK5QtamsCnJ5leDnyt1sjH9SiUqIS25tAXl0IMqYcoPNkRs= Received: by 10.210.10.1 with SMTP id 1mr6065059ebj.167.1211144512605; Sun, 18 May 2008 14:01:52 -0700 (PDT) Received: from epsilon.local ( [89.214.185.160]) by mx.google.com with ESMTPS id c24sm10558692ika.4.2008.05.18.14.01.50 (version=SSLv3 cipher=RC4-MD5); Sun, 18 May 2008 14:01:51 -0700 (PDT) Message-ID: <4830993B.5070400@FreeBSD.org> Date: Sun, 18 May 2008 22:01:47 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mike Meyer References: <482E93C0.4070802@icyb.net.ua> <20080517133037.3a3935db@bhuda.mired.org> <48305044.7000007@FreeBSD.org> <20080518140650.2691af1c@bhuda.mired.org> <48307700.70304@FreeBSD.org> <20080518152937.774cf492@bhuda.mired.org> In-Reply-To: <20080518152937.774cf492@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org Subject: Re: rdmsr from userspace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 21:01:54 -0000 Mike Meyer wrote: > > I don't think that would work - you'd have to register all those > hexadecimal strings as sysctl names. Yes, in theory you could also hack sysctl in a way that it doesn't walk when you do a sysctl -a, but works fine when you issue sysctl dev.cpu.N.0xffaabbcc, for example. I would be against this, though, because this will be like "sysctl on steroids", a really crude hack. > You could do an interface like > this, but the calling program would have to use sysctlnametomib to get > dev.cpu.N.msr, then append the MSR number to the results. Not really > very pretty. If you want to allow the user to poke at arbitrary msrs, > this would be a way to do it with sysctls, but the file api is > probably better. Agreed. > On the other hand, if you want to allow access to the fixed set of > documented msr's (for each cpu model, anyway), then handing back that > fixed set as an array would be a better approach, and would have the > advantage of not having to deal with invalid requests (non-existent > MSRs, 1-byte reads/writes of multi-byte MSRs, etc). > > On the other hand, it might be more useful - *especially* if the MSRs > move around depending on processor types (I honestly don't know) They do. At least on Intel (I don't know about AMD). But this "moving" is not documented. > - to > provide a "named" interface: > > dev.cpu.0.msr.mtrr > dev.cpu.0.msr.arr > dev.cpu.0.msr.efer > > and so on. You'd register the names when the module was initialized, > and would only register the ones that actually existed. You'd then > never have to deal with a request for a non-existent MSR, because the > sysctl call would return an error to the calling program without ever > calling your handler. > > Of course, you can *combine* these two approaches, and have: > > dev.cpu.0.msr.all # returns an array of all available msrs > dev.cpu.0.msr.have # an array of the available msrs > > but at this point it's just blue sky speculation... > >> I'll have to think about whether or not I like this interface. > > Actually, I'm more interested in why there seems to be a dislike > of file-based interfaces in favor of sysctls in the freebsd > community. Speaking for myself, sometimes sysctl is an interface that "just works" and is simple enough. Of course there are some types of structured data that don't belong to sysctl, but overall, I don't think we are abusing it. Creating a /dev node, handling ioctl's, etc. is much more work and error prone. That's all. At least for me. Regards, -- Rui Paulo