From owner-freebsd-hackers Sun Jan 16 8: 7:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 6ECD514DD7 for ; Sun, 16 Jan 2000 08:07:21 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 129sD0-000DTI-0V; Sun, 16 Jan 2000 16:07:19 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id QAA00654; Sun, 16 Jan 2000 16:07:27 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 16 Jan 2000 16:06:25 +0000 (GMT) From: Doug Rabson To: Michael Kennett Cc: hackers@freebsd.org Subject: Re: Use of newbus in sys/pci/pci.c In-Reply-To: <200001150332.LAA24167@laurasia.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Jan 2000, Michael Kennett wrote: > Hello All, > > I have a question on the sys/pci/pci.c code, and its use of the > newbus architecture. An example of the code in question is: > > static struct resource * > pci_alloc_resource(device_t dev, device_t child, int type, int *rid, > u_long start, u_long end, u_long count, u_int flags) > { > struct pci_devinfo *dinfo = device_get_ivars(child); > ^^^^^ Looks wrong > struct resource_list *rl = &dinfo->resources; > > return resource_list_alloc(rl, dev, child, type, rid, > start, end, count, flags); > } > > I don't understand the line that extracts the ivars from the child > device. Isn't it the case that the ivars are a property of the bus > device (dev)? In any case, the child device might not be directly > descended from the pci bus (e.g. it could be attached thru' the > bridge isab0: ). The ivars are for bus-specific per-child information. The resource locations for pci devices fall into this category and the information is stored in a pci-private structure in the child device's ivars field. This code is slightly dubious for the case when child isn't a direct descendant of dev (i.e. a grandchild etc). In this case, the ivars pointer would be read but not indirected through since the first thing resource_list_alloc() does is check for this and pass the allocation up the tree. It should be safe but its certainly dubious. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message