From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:46:53 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 73DB5106564A; Mon, 9 Jul 2012 03:46:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8E798FC0A; Mon, 9 Jul 2012 03:46:52 +0000 (UTC) Received: by werp13 with SMTP id p13so7447212wer.13 for ; Sun, 08 Jul 2012 20:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ALLlTh0eWvI4aHxdoIL83Z53L3zNOWvCsKlEW9UR30U=; b=fHSfS0XlH/2vRaCiEWmLtt5yBn/7SV26JYFLU4AAgEPf1gwS0m2ur4hN/pizZB162/ yCvFhK5jp8qdlUBESZj6Ljjs0FeSqkk/oxS8cjJS05pua3NjX8e+OsvyqsUe3RLc1HV8 DJgAZkEAwLdzgBIKEvQNzhyQvFUvqWsZAAWK3CZc/l2DecgI+wJyBzlYbdJCVDWd/J/H t4TIgtAtHAwXy15N577TBa/7wIkQ/v9dtywJ/e6QrsdD0Z6SxEDpmHnSzDEPC7jRCJ9w z3Gyp0zuf3AejNvEC4o2bvfK/HtjS1cAl0RLbDJ+x5XLm0UxIrAMv6ZS3OOEDjVcMcmH oeFQ== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr14189629wes.108.1341805611796; Sun, 08 Jul 2012 20:46:51 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:46:51 -0700 (PDT) In-Reply-To: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> Date: Sun, 8 Jul 2012 23:46:51 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 03:46:53 -0000 On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: > > On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>> >>> 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. >>> >>> 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 doe= sn't matter quite how things are done. >>> >>> So I'm not sure I understand what you are saying here. >>> >> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >> use both interfaces. There is no generic way for dev0 to export >> independent ivars for both interface. For now, I restricted the >> function of the second interface not to need ivar, but that's kind of >> hackish. > > Only if the IVARs for interface A and interface B have overlapping values= . If the Ivar keys don't overlap, then there's no problems at all. Certai= nly less hackish than not using them at all. Since dev0 knows the layout o= f the ivar that it set on its child, this presents no problems at all. It = would return the values from A from the right part of the ivar, and those f= rom B in the right part. Apart from the coordination of Ivar numbers, as I= outlined in my last post, there's no issue here. > I think we should not be talking about the same API here. I have no idea what you mean by "the key to value translation", nor "Ivar numbers". What I refer to is that device_set_ivars() / device_get_ivars() acts on a single instance variables from `struct device': `ivars'. In that case, I do not really see how to set that specific field to two distinct values for each interfaces. - Arnaud > Warner > >> - Arnaud >> >>> The problem, more basically, is that the ivar keys are not unique. Cur= rently, there's no bits used in the key to define the values to be non-over= lapping. For example: >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> 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 s= cale too well. Given that there's only about a dozen or two in the tree, t= hat's right at the moment, it wouldn't be hard to do something like: >>> >>> enum ivar_namespace { >>> IVAR_PCI =3D 1, >>> IVAR_PCCARD, >>> IVAR_USB, >>> etc >>> }; >>> #define IVAR_SHIFT 16 >>> >>> and the above could be changed to: >>> >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> and then we'd have an unambiguous key, and the bus could easily impleme= nt multiple interfaces. >>> >>> but then again, most of the existing interfaces in the kernel are mutua= lly exclusive, so you could implement this just for your new interfaces. >>> >>>> Unless I am mistaken, ivar are the only way for a parent can transmit >>>> information to a child. I can not simply implement a new METHOD to get >>>> that ivar as the device implements multiple time the same function >>>> (actually, up to 4 time for one, 3 for the other, with possible >>>> crossovers...), each one physically distinct. Each child is being tied >>>> to a pair. Thus, I need to pass each child discriminator(s) for each >>>> interfaces right after having been *created*, which cannot be done >>>> later on. Of course, it is out-of-question to have crossover in the >>>> interfaces definitions. >>> >>> ivars are but one way to communicate this. However, they are the gener= ic way to convert a key to a value and store a key on a value. I don't rea= lly understand what you are trying to say here, perhaps an example would he= lp illustrate what you are trying to do, since I don't quite understand the= problem here. >>> >>>> The best way I could achieve this currently is to pass the child's >>>> device to its parent, and do a lookup based on that pointer to get >>>> information I need, but erk.... >>> >>> That doesn't make any sense. The child's parent already sets that chil= d's ivar when the child is created. The child's parent already gets a poin= ter to the child when asked to do the key to value translation. Again, per= haps an example would help here. >>> >>> Warner >