Date: Sun, 22 Jul 2012 20:22:33 -0600 From: Scott Long <scottl@samsco.org> To: Julian Elischer <julian@FreeBSD.org> Cc: FreeBSD Current <current@FreeBSD.org> Subject: Re: PCIe hotplug Message-ID: <EABF0570-55F1-4758-B0FF-62561FFAC4EF@samsco.org> In-Reply-To: <500A0E24.80101@freebsd.org> References: <500A0E24.80101@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EABF0570-55F1-4758-B0FF-62561FFAC4EF>