From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:47:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4050F16A4CE for ; Thu, 26 Feb 2004 10:47:14 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id C094A43D39 for ; Thu, 26 Feb 2004 10:47:13 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 40782530F; Thu, 26 Feb 2004 19:47:12 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 904EC5309; Thu, 26 Feb 2004 19:47:01 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 63C2333C71; Thu, 26 Feb 2004 19:47:01 +0100 (CET) To: "M. Warner Losh" References: <20040226.112045.82374099.imp@bsdimp.com> <20040226.113514.94846192.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:47:01 +0100 In-Reply-To: <20040226.113514.94846192.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:35:14 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:47:14 -0000 "M. Warner Losh" writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : 1) it is immensely easier to access > From whose point of view. Programmatically. The in-kernel implementation is much simpler, and the userland code required to access it will also be simpler. Accessing individual devices (once you know where they are) should also be much simpler since devinfo only gives you "all or nothing". > : 2) it gives drivers a well-defined place to put their per-device > : sysctl variables - devinfo doesn't address that issue at all > That is a good reason to transitioning to this, so long as we can come > up with a good way to represent detached nodes. As long as they have a device_t, it should be a piece of cake. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no