From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:39:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C49106566C for ; Mon, 9 Jul 2012 04:39:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 039878FC17 for ; Mon, 9 Jul 2012 04:39:09 +0000 (UTC) Received: by ggnm2 with SMTP id m2so11210530ggn.13 for ; Sun, 08 Jul 2012 21:39:09 -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=2PU0KfHfGfWSG2xPJJRgEFUcsAIsKBa/gwQArzMPjPE=; b=iSmpg7NzVyhRKLYOmWj+41WZ+u/AHaL7UI4wK8KUIOc1DmcD/IQU4DeqrBnr1qgEiv ayjkJqX87Ij3g27IEZXeHtdkdnVYDiSoEesapiuYsbqqEkjNnqt3N+liWfqMMvQ2oWte nLtd1Z25+eogzxJDFvxI6T3BYnuVpqgmAZT+eylvEq90RKHw03+lB2vsZ6Ugc1TGDISC d3YdjFZXf1tn0kMbQBfNnx2Zp9TBqxRQ2iXEcjPFV3ovlewplgOdb5utOyfdktzLyS+Z F6vq4kBpwU9nXG4c7h0q0NmvRSMRbrviu9mo+pc3VQy6ZKaoKe9PUd3sajVhnhckzhdU J6rg== Received: by 10.66.74.97 with SMTP id s1mr62555882pav.11.1341808749146; Sun, 08 Jul 2012 21:39:09 -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 jp10sm26913168pbb.16.2012.07.08.21.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:39:08 -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: Date: Sun, 8 Jul 2012 22:39:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmBR/a637MN5rSH8aP1+9vBZlXE9aLZw7u0Opz3DinlUyPOEm3Bhr4Gxb3uYFhj9h8e3Z+K Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. 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, 09 Jul 2012 04:39:10 -0000 On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than = one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old = way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been = per-interface, >>> not global and unique to one device. >>=20 >> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>=20 >> So I'm not sure I understand what you are saying here. >>=20 >> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>=20 >> enum ivar_namespace { >> IVAR_PCI =3D 1, >> IVAR_PCCARD, >> IVAR_USB, >> etc >> }; >> #define IVAR_SHIFT 16 >>=20 >> and the above could be changed to: >>=20 >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>=20 >> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>=20 > ok, I think I got it now. You and I are exactly saying the same thing, > just in different terms; there is no way to currently specify multiple > independent (/overlapping) ivars in a child... There's no way to support overlapping IVAR keys, yes. However, if you = are designing the ivars for multiple inheritance, then you'll need to = make them non-overlapping. Thankfully, this is trivial to do. Warner Warner=