From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 02:46:34 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68048106564A; Mon, 23 Jul 2012 02:46:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2F48FC0A; Mon, 23 Jul 2012 02:46:33 +0000 (UTC) Received: from theimac.samsco.home (theimac.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q6N2MTRo080670; Sun, 22 Jul 2012 20:22:30 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <500A0E24.80101@freebsd.org> Date: Sun, 22 Jul 2012 20:22:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500A0E24.80101@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1278) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: PCIe hotplug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 02:46:34 -0000 On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: > Is anyone looking at PCIe hotplug support? >=20 > I'm especially interested if anyone has a strategy for device = re-insertion and reassociating > the reinserted device with its old device_t so that it gets the same = unit number.. > (assumes access to a serial number or similar) > Even if it is put back into a different slot. >=20 Would the PCI system be responsible for figuring out this serial number? = I don't think that it can, but it's a question to answer, I guess. If = it can't then it's up to the driver to generate a unique cookie that = would be stored by the PCI subsystem. This cookie would have to be = based off of data that can be retrieved from the PCI config space and/or = VPD space, since anything more would require resource allocation, which = is only allowed in the DEV_ATTACH phase, and once you've hit that phase = you've already pretty much sealed the deal on unit number assignment. So what would probably happen is that the PCI layer provides a ring = buffer of cookie storage and a set of accessors for the drivers. The = cookies would map to a key-value pair with the device unit name and = number. During probe, a driver can look at PCI config space and = generate a cookie. That cookie can then be communicated up to the PCI = layer for storage. Maybe the driver calls a match routine that returns = a unit number on match and a store on failure, then the driver calls a = set_unit_number accessor. Only the driver that wins the bid would win = the unit number reassignment or cookie storage. Or maybe the driver = passes the cookie up as part of its return code, and the match and unit = assignment happens automatically. Drivers that don't want to = participate in this simply wouldn't, and everything would continue to = operate the same way. The two sticky parts are rogue/buggy drivers that = abuse the api and cause a flood of cookies to be generated, and = questions on when a unit number is eligible for reuse. For the first = one, a ring buffer of cookies would solve the immediate problem, but you = might still have some risk of drivers selectively wrapping the buffer = for whatever accidental or evil purpose. For the second problem, maybe = a unit number stays persistent only if the PCIe hot remove mechanism = requests it, and then only until the ring-buffer wraps. Scott