From owner-freebsd-hackers@FreeBSD.ORG Tue May 30 13:58:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB19E16A7DD for ; Tue, 30 May 2006 13:58:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F0343D46 for ; Tue, 30 May 2006 13:58:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k4UDwBgK031540; Tue, 30 May 2006 07:58:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 30 May 2006 07:58:18 -0600 (MDT) Message-Id: <20060530.075818.-820706528.imp@bsdimp.com> To: avalonwallace@gmail.com From: "M. Warner Losh" In-Reply-To: <87ab37ab0605300642ja608c97s24836a317cdac24@mail.gmail.com> References: <20060524153153.GF49081@funkthat.com> <87ab37ab0605280309s15a31cb4yc8a54be1af5472dd@mail.gmail.com> <87ab37ab0605300642ja608c97s24836a317cdac24@mail.gmail.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dely.l.sy@intel.com, scottl@samsco.org Subject: Re: misc questions about the device&driver arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 13:58:36 -0000 In message: <87ab37ab0605300642ja608c97s24836a317cdac24@mail.gmail.com> "william wallace" writes: : Sir： : I have got the way to map linux pci access way to the BSD way :) : now ,several more question ,wondering :( : FIRST : struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int : f, size_t size) : struct cardbus_devinfo { : struct pci_devinfo pci; : uint8_t mprefetchable; /* bit mask of prefetchable BARs */ : : so what happen when dinfo = (struct cardbus_devinfo : *)pci_read_device(brdev, bus, slot, func, sizeof(struct : cardbus_devinfo)); : can we use this magic as a common way to wrap common guts? Yes. It is already there when you go throuh the proper interface. Take a look at ivars. struct pci_devinfo is not for anybody but a bus to use. : SECOND : what should we do to destroy a device and hot remove it from the system ? : 1 pause the application impractical. What application? This is an async event, and upper level drivers have to cope. If they don't, we're screwed anyway. If a device can disappear, then we have to make sure that the drivers support it. : 2 device_detach(devlist[tmp]); That's what we do right now in cardbus. : 3***_release_all_resources(busdev, dinfo); Drivers are responsible for doing this, not the bus. : 4 device_delete_child(busdev, devlist[tmp]); That's what we do right now in cardbus. : 5 pci_freecfg((struct pci_devinfo *)dinfo); Sounds good. : 6 shutdown power of the slot Yea. : so what exactly happens between 2 and 5? : THIRD : Because the PCIE configure space is 4k long ,shall we change the : #define PCI_REGMAX 255 : to facilitate the PCI express config R/W? Maybe. Lemme investigate because PCIe changes this from a well known constant for all pci busses, to a variable one... Warner