From owner-cvs-all@FreeBSD.ORG Fri Feb 4 16:51:07 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47D4116A4CE; Fri, 4 Feb 2005 16:51:07 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B41843D39; Fri, 4 Feb 2005 16:51:06 +0000 (GMT) (envelope-from dfr@qubesoft.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.1/8.13.1) with ESMTP id j14Gp2N8024547; Fri, 4 Feb 2005 16:51:02 GMT (envelope-from dfr@qubesoft.com) In-Reply-To: <20050204.094615.123623745.imp@bsdimp.com> References: <5539563a425020d35ef1878057f4f85d@qubesoft.com> <20050204.093654.114275559.imp@bsdimp.com> <4f339e2416fad9f0baab265cec8a744d@qubesoft.com> <20050204.094615.123623745.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Fri, 4 Feb 2005 16:51:03 +0000 To: "M. Warner Losh" X-Mailer: Apple Mail (2.619.2) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.qubesoft.com cc: cvs-src@FreeBSD.org cc: marcel@xcllnt.net cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org cc: nate@root.org Subject: Re: cvs commit: src/sys/ia64/ia64 machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 16:51:07 -0000 On 4 Feb 2005, at 16:46, M. Warner Losh wrote: > In message: <4f339e2416fad9f0baab265cec8a744d@qubesoft.com> > Doug Rabson writes: > : > : On 4 Feb 2005, at 16:36, M. Warner Losh wrote: > : > : > In message: <5539563a425020d35ef1878057f4f85d@qubesoft.com> > : > Doug Rabson writes: > : > : > : > : On 4 Feb 2005, at 16:14, M. Warner Losh wrote: > : > : > : > : > In message: <84e9ba659174ea3f7c7b2930c0ae3759@xcllnt.net> > : > : > Marcel Moolenaar writes: > : > : > : > I'm not sure if my approach is correct -- should different > : > drivers > : > : > for > : > : > : > the same hardware share the same devclass? > : > : > : > : > : > : A datapoint: sio(4) and uart(4) are different drivers for the > : > same > : > : > : hardware. > : > : > : They don't share the devclass. > : > : > > : > : > Neither do they share the same name. > : > : > : > : Just to make things clear, if two drivers use the same name, they > : > will > : > : always share the devclass automatically (whether or not they use > the > : > : same variable to reference the devclass) and will allocate > : > : non-conflicting unit numbers. > : > > : > Cool. I'd thought I'd wound up with two instances of ed0 when I > had > : > different devclasses in the if_ed_isa and if_ed_pci files once > upon a > : > time... > : > : This shouldn't be possible - both the driver registrations should go > : through devclass_find_internal() to find their devclasses and this > : always searches for an existing class before it creates one. If this > : happens then its a serious bug... > > I think I had this problem in 4.0-current before 4.0 release. Maybe > there used to be a bug, or I did something stupid... > > If this is the case, why then do we have the allocation of devclass in > the drivers and not just leave it to subr_bus.c? It is in subr_bus.c - the drivers end up in driver_module_handler() where they sort out the devclass and add the driver to the parent's driver list etc. You can call devclass_create() if you have some other unusual reason (perhaps some some generic code which does cdevsw[] handling for ell "foobar" devices or whatever) but it also ends up going through devclass_find_internal() which returns the existing devclass if there already is one. >