From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 9 02:07:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C70031065672 for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 927C18FC0C for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19700680pbb.13 for ; Sun, 08 Jul 2012 19:07:57 -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=Qvwq/c+hjCJyYlYmS5vgdJVoqX3YK0aM5QlBryKHhCw=; b=jSoKYz9u/W0UXV45FUxDHkKq91MjNb4qxzFGkVj7C6XE9OoP1ZtcqTQ4pe9n73VlNi H+I4PTzHuYZ+419xgOfFLeeGuYvokCdvHhGIaY5hUkM1aJZFyFS2B6q2doUB2ZJkOBMX fq7VNIVOKFCgELyuLZZ7vWZ02Y8m93H/JDwTfGyv5FStu8SqMHv4SvccQZKbHyPHg6Kd 8hYSv7tnv1guP60NX15x6tSvuAN6rnMMkhC1SqgOJ2sIHVuNLZ2niOyukOZsgOfyUECV w21EqQn+NqX/P7nX+AoksV6Ude3EonjLc7jW5U7GhlbnhueZoaaNfo0Pi4vD85p25AY1 67ww== Received: by 10.68.236.129 with SMTP id uu1mr56103384pbc.77.1341799677392; Sun, 08 Jul 2012 19:07:57 -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 or5sm7285160pbb.44.2012.07.08.19.07.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 19:07:57 -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 20:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl1fANXmBhFUYoO0MhquE4ZXFNsI7/6kPFMmfa/UgbpVlE+Fe43dopYaMlJ5134hqtdY5JM Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:07:57 -0000 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 doesn't matter quite how things are done. So I'm not sure I understand what you are saying here. 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, .... }; 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: 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 = mutually 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 really 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 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 = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. Warner=