From owner-cvs-src@FreeBSD.ORG Thu Jun 3 08:32:50 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE7416A4CE; Thu, 3 Jun 2004 08:32:50 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3131043D48; Thu, 3 Jun 2004 08:32:50 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i53FTpkx045989; Thu, 3 Jun 2004 09:29:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Jun 2004 09:29:54 -0600 (MDT) Message-Id: <20040603.092954.114645644.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040603.091250.82990500.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: mux@FreeBSD.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: scottl@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 15:32:50 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "M. Warner Losh" writes: : > des@des.no (Dag-Erling Sm=F8rgrav) writes: : > : Scott Long writes: : > : This should be fairly easy to do. I'll try to come up with some : > : patches. : > How about an API? How does the driver deal with the global/instanc= e : > variable split? If I set dev.fxp.gerbil to 1 and dev.fxp.1.gerbil = to : > 23? Is that order dependent? : = : that's up to the driver author to decide. That's why I want to know the API the driver will use so that it can be judged as sufficient or not. I also think we should have some kind of default design pattern. It would also be good to have some hook to the boot loader tunables as well. This is easy to do for static ones, but non-static ones need some glue to make it happen. : so far, what I think I'll do is give each devclass its own context an= d : node, and place each device's node below the devclass's node, so you : get : = : dev.fxp.foo : dev.fxp.fxp0.%desc : dev.fxp.fxp0.%driver : dev.fxp.fxp0.%location : dev.fxp.fxp0.bar : = : you can't have the driver be the parent, because some devices have no= : driver (but they all have a class), and I want to use dev.fxp.fxp0 : instead of dev.fxp.0 on the off chance that there might be multiple : devices in a class with the same unit number but different names. That can't happen. If it does, I want other things to break as well so we notice when it does. I'd rather see symetry with the hints mechanism. Although it is safe to assume that people have written drivers with numbers in them. We have tsc2011, tsc2050, etc for some of the modules that we do and this has worked since 3.x at least. These names will work either way with your way or my way, but I wanted to point it out. Warner