From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 21:03:08 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 8F4B21065670; Sun, 18 May 2008 21:03:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4923D8FC1B; Sun, 18 May 2008 21:03:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1Jxq26-000JMB-G4; Mon, 19 May 2008 00:03:06 +0300 Message-ID: <48309983.3070900@icyb.net.ua> Date: Mon, 19 May 2008 00:02:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080320) MIME-Version: 1.0 To: Rui Paulo References: <482E93C0.4070802@icyb.net.ua> <482EFBA0.30107@FreeBSD.org> <482F1191.70709@icyb.net.ua> <482F1529.5080409@FreeBSD.org> <20080517175312.GM18958@deviant.kiev.zoral.com.ua> <48304F9D.9030406@FreeBSD.org> <20080518181549.GZ18958@deviant.kiev.zoral.com.ua> <48307658.2080502@FreeBSD.org> In-Reply-To: <48307658.2080502@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , 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:03:08 -0000 on 18/05/2008 21:32 Rui Paulo said the following: > > Yes, but I still don't like having everything mixed up in one driver. At > the very least, I would like us to have two drivers. One for the > microcode update and the other driver for the rest. > > I would like to see a microcode update utility (driver + something to > parse Intel's file aka devcpu-data) in the base system, but not "the > rest", though. Well, I am not sure what is a basis for such a requirement. As I pointed out before we already have /dev/pci and /dev/io and those are not going to go away, because there are quite reasonable applications that require those devices (and wide-spread too). And I think that sufficiently structured (via ioctl interface) access to CPU is also needed for some quite useful (and reasonable) userland applications. I can understand efforts to prevent foot-shooting, but I can not understand an approach of limiting abilities of a (sufficiently) privileged user. After all, he/she can rebuild a kernel and put all they need into it. -- Andriy Gapon