From owner-p4-projects@FreeBSD.ORG Fri Sep 15 17:08:33 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 120A516A415; Fri, 15 Sep 2006 17:08:33 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D5B16A403 for ; Fri, 15 Sep 2006 17:08:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 826F743D67 for ; Fri, 15 Sep 2006 17:08:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8FH89i5052169; Fri, 15 Sep 2006 13:08:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Hans Petter Selasky Date: Fri, 15 Sep 2006 12:43:50 -0400 User-Agent: KMail/1.9.1 References: <200609151417.k8FEHSFx098273@repoman.freebsd.org> <200609151039.16523.jhb@freebsd.org> <200609151710.17572.hselasky@c2i.net> In-Reply-To: <200609151710.17572.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609151243.50388.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 15 Sep 2006 13:08:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1885/Fri Sep 15 07:19:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Perforce Change Reviews Subject: Re: PERFORCE change 106148 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2006 17:08:33 -0000 On Friday 15 September 2006 11:10, Hans Petter Selasky wrote: > On Friday 15 September 2006 16:39, you wrote: > > On Friday 15 September 2006 10:17, Hans Petter Selasky wrote: > > > http://perforce.freebsd.org/chv.cgi?CH=106148 > > > > > > Change 106148 by hselasky@hselasky_mini_itx on 2006/09/15 14:17:12 > > > > > > Initialize all driver_t structures by record. Bugfix: Some of the > > > modem drivers did not use the "ucom_devclass". Make sure that all > > > modem drivers use this devclass. > > > > That doesn't actually matter. Also, no other drivers use this style to > > initialize their driver_t. If you really wanted to do a change, you should > > change them to use DEFINE_CLASS macros to define a KOBJ class instead. > > Ok. Will consider that next time. > > > BTW, why the devclass doesn't matter: the devclass_t is just a pointer to > > a device class. The device classes are based on the driver name, so if you > > add a new driver with the name "foo", it will look up the device class by > > name ("foo"), creating one if it doesn't exist. > > My implementation for NetBSD works like this: This is FreeBSD I'm talking about. > > It then saves a pointer to > > that device class object in the devclass_t pointer specified in > > DRIVER_MODULE(). So, by making them all share the same devclass_t, they are > > all just going to overwrite the same pointer when the driver module loads. > > No, wrong. The devclass_t pointer is not overwritten if it is already > initialized! Umm. It's overwritten, but to the same value. Go look at the actual code. This is the function that is called via SYSINIT via DRIVER_MODULE(): /** * @brief Module handler for registering device drivers * * This module handler is used to automatically register device * drivers when modules are loaded. If @p what is MOD_LOAD, it calls * devclass_add_driver() for the driver described by the * driver_module_data structure pointed to by @p arg */ int driver_module_handler(module_t mod, int what, void *arg) { ... dmd = (struct driver_module_data *)arg; ... switch (what) { case MOD_LOAD: ... if (driver->baseclasses) { const char *parentname; parentname = driver->baseclasses[0]->name; *dmd->dmd_devclass = devclass_find_internal(driver->name, parentname, TRUE); } else { *dmd->dmd_devclass = devclass_find_internal(driver->name, 0, TRUE); } break; ... } The writes to dmd_devclass are writing to the 'static devclass_t' you specify in your DRIVER_MODULE() line. As I mentioned earlier, devclass_t isn't a struct, it's a pointer to a struct: typedef struct devclass *devclass_t; Basically, passing a devclass_t into DRIVER_MODULE() just gives you a pre-intialized pointer to your devclass. The devclass's aren't bound to that devclass_t though, they are bound to the name. Thus if you have: static devclass_t foo_class, bar_class; static driver_t foo_driver { "foo", ... }; static driver_t bar_driver { "foo", ... }; DRIVER_MODULE(..., foo_driver, foo_devclass, ...); DRIVER_MODULE(..., bar_driver, bar_devclass, ...); foo_devclass and bar_devclass will both point to the same device class object. > > To be honest, most drivers don't even use the devclass pointer, and I'd > > actually like to axe it and make the few drivers that do care use > > 'devclass_find("foo")' when they need the devclass pointer instead. > > I need the devclass to get unique unit numbers. Again, go look at the actual code, it can still call devclass_find_internal(), but it is not required to save the pointer to do so. -- John Baldwin