From owner-freebsd-current@FreeBSD.ORG Mon Jul 23 04:11:36 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 ACB831065673 for ; Mon, 23 Jul 2012 04:11:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9C48FC0C for ; Mon, 23 Jul 2012 04:11:36 +0000 (UTC) Received: by yenl8 with SMTP id l8so5933631yen.13 for ; Sun, 22 Jul 2012 21:11:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=yojWHAbzwaVOcLaPDBhXt2s2VstMkHqTXw7W/U0/v4o=; b=OpOapKBwhQZFoaRDcirbPx5+f+p2tIHNFDL83/pLKUwdaYL9fvtJR3m4zIikrNLChl er+oCfb5wMlWjxJlz4YEWZ89dEW7N3IvMaSOqFxrQmd344loNwxVW70UrwuZldq8q6tP Jv0b6xHHESvhLLsV2Uu21VFGrD+CIzXU9PgwStqmitVThCykaXy+JALtKLdFNpASjm0P wKWV+RUJzICywzj7QDsXKkfC7DrvjdDLf7xGh8q2li9uaRUsbQK8yq0O1D8tzQ5+C4Lb 7xZj5UJHdkWVcsCfi3yLKUbyq3QyfSWYl6yG8/xbx2DPTkr9ljROkbgScWUvSVd/P3fy vAZQ== Received: by 10.66.74.97 with SMTP id s1mr27816457pav.11.1343016695275; Sun, 22 Jul 2012 21:11:35 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nj4sm9109344pbc.5.2012.07.22.21.11.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jul 2012 21:11:34 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120722231234.6f748d05@kan.dyndns.org> Date: Sun, 22 Jul 2012 22:11:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500A0E24.80101@freebsd.org> <20120722231234.6f748d05@kan.dyndns.org> To: Alexander Kabaev X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk4joN2GOQsBx/iICvt+RyxIyl0PjU7uUa2pFOtp6PQCC2LrU6AcQ6A+wcw/A8DsmuyCtaR 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 04:11:36 -0000 On Jul 22, 2012, at 9:12 PM, Alexander Kabaev wrote: > On Sun, 22 Jul 2012 20:22:33 -0600 > Scott Long wrote: >=20 >>=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 >=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. There's a reason that PC Card and CardBus never supported this at all. = The assumption was that reconnecting devices is so cheap that it isn't = worth the bother. This is true for all but some specialized devices = today: network information is easy to reconstruct, storage drives are = easy to reconfigure (since we already fail all in-flight transactions = when the device goes away), etc. I can see some advantage to having = storage cope, but there already geom classes that can help people code = when drives can go away. > PCI-e hotplug proper is very much orthogonal to the question of unit > numbering and IS worth supporting. Yes. totally agreed. Warner