From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 03:12:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 865C2106564A; Mon, 23 Jul 2012 03:12:43 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17C538FC0C; Mon, 23 Jul 2012 03:12:42 +0000 (UTC) Received: by vbmv11 with SMTP id v11so5323895vbm.13 for ; Sun, 22 Jul 2012 20:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=pWffL+RJVN7NgqekEwEQ42XWM2G5MwsoGhlW8N21ph8=; b=GnVDepBsbsQNhHCnIjk1FU7VeEpZXhzAeAR8oqooFFtsG9+jlg+h12d3FL913HTRbI OvwZbBnNm5EvQ18UJvGWdIO1X9flHMbyq48yOB0GzYyozue5sXRmSRywBT/Amg9skvaJ 9iK+U6Ck+itniTknoml9hMGmCYDg0PSij/FqNIY/G/sage6zKBWUGeiLsQJr4c3Ibhnr paZI42nIKfyT4SEcik/xrD1KfyLrwJK/wZowRJeoYUACSMvgr+DUjMEMUvYbaZYvDKs3 bCW9q/EoJHA3W01c1EcvN36jw24C86BpAFNISxOipTj3MjHOcMoI0jLtnQxgJ6PkboWU z9Jw== Received: by 10.220.224.66 with SMTP id in2mr7827428vcb.51.1343013162301; Sun, 22 Jul 2012 20:12:42 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id bn5sm9308777vdb.19.2012.07.22.20.12.40 (version=SSLv3 cipher=OTHER); Sun, 22 Jul 2012 20:12:41 -0700 (PDT) Date: Sun, 22 Jul 2012 23:12:34 -0400 From: Alexander Kabaev To: Scott Long Message-ID: <20120722231234.6f748d05@kan.dyndns.org> In-Reply-To: References: <500A0E24.80101@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2IdXL7eBHf6p+xCXoD/Wg8_"; protocol="application/pgp-signature" Cc: Julian Elischer , 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 03:12:43 -0000 --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 22 Jul 2012 20:22:33 -0600 Scott Long wrote: >=20 > On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: >=20 > > 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 >=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. >=20 > 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. >=20 > Scott >=20 I do not think the whole problem as depicted by Julian is even worth solving. Why keeping any data for the device that might _never_ come back? What if the device hierarchy just starts from the PCI-e and extends upwards and user still holds on to some vestiges of a previous device chain (say, by keeping a character control device sharing the same unit number open, common practice)? Reusing unit number is much trickier then, and might not be even possible. So, before one jumps into 'how', can we agree on 'why' first? When device goes away, it is not just this device's device_t that is disappearing, it is a whole tree rooted at that device. I see no point in trying to reconstruct that. PCI-e hotplug proper is very much orthogonal to the question of unit numbering and IS worth supporting. --=20 Alexander Kabaev --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQDMEnQ6z1jMm+XZYRAqtHAKDF9LaUIdoXrPjDy+tbnY8BuXYhtQCgoNMt RIP0DUgeag0wKtOVtMPsB/8= =2hh9 -----END PGP SIGNATURE----- --Sig_/2IdXL7eBHf6p+xCXoD/Wg8_--