From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:26:01 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 DB2721065677; Mon, 9 Jul 2012 03:26:01 +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 4902A8FC0A; Mon, 9 Jul 2012 03:26:01 +0000 (UTC) Received: by werp13 with SMTP id p13so7439734wer.13 for ; Sun, 08 Jul 2012 20:26:00 -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=fJ27icMVKEL0eJOZFIhObd1y0nbMis9Ks6oAQn0CXPU=; b=SKycEEWZ9rbahqOE6ou1VDv92MdwoBPXCIuYki65u3IJaCcmGmmWGqoWwcy13I10PN pUpvCIv0qC49C5ruZP7P82dcczcv6mlMfwUZ9D+RkUadFvhmPLMFHQtnOCf/bQla8aKP grpSKcIp9Wun8Hh3VnxgOPp7nsDgMiCdriXCuN+OycYo8mq9W9I3NPnkS08f5AnWW7Uc Yo2hqmkpCgd9E1RNjFrqPJ5/hKIONIq8POJIv0jSPT1V2agXJl3APbBk4Og06ps5pBIx rm1ynOeA1IXvQ2vTdJQjPvgQqEjjFGGSo4Tr44LBYD1rsUnYy8iKknDDj3Ji68p6m0X3 DH6w== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr25853106wiz.22.1341804360296; Sun, 08 Jul 2012 20:26:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:26:00 -0700 (PDT) In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> Date: Sun, 8 Jul 2012 23:26:00 -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:26:02 -0000 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 t= he ivar looks like, because the interface is totally private to the bus. S= o long as it returns the right thing for any key that's presented, it doesn= '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. - Arnaud > The problem, more basically, is that the ivar keys are not unique. Curre= ntly, there's no bits used in the key to define the values to be non-overla= pping. 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 sca= le too well. Given that there's only about a dozen or two in the tree, tha= t'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 implement= multiple interfaces. > > but then again, most of the existing interfaces in the kernel are mutuall= y 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 generic= way to convert a key to a value and store a key on a value. I don't reall= y understand what you are trying to say here, perhaps an example would help= illustrate what you are trying to do, since I don't quite understand the p= roblem 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 child'= s ivar when the child is created. The child's parent already gets a pointe= r to the child when asked to do the key to value translation. Again, perha= ps an example would help here. > > Warner