From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 05:20:13 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 29D55106564A for ; Thu, 12 Jul 2012 05:20:13 +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 C40178FC19 for ; Thu, 12 Jul 2012 05:20:12 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2320608ggn.13 for ; Wed, 11 Jul 2012 22:20:12 -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=gQj15LefXJAW00EkiFPzDQ1KcGKgEl1c2SqZv3ONKC4=; b=jBk+luVI0Gd5ozIx5Ww5CTYYTdjo/m49HFLzAfE5XVRW2h2vHW9smregBeocFOeBQ+ 9Oi57w3Yj2FOoMIzjVr3IknMHiPmrN8L+VFY2CnJa7GiVnzUgFzfU8n5x5n6Ae+AZnaL nl9jM7js37Fh/SpZvpLNnxodH7G0Ot3BZGFHLYDdh9NyJep2O4PaNPhWZ2NFkhOAX8Fx k9ZbReQNdpb+ZwCK1KHm4wJXIBjmWh/noq95JqdBNjVMJmZ99azgRkOvZ+eCr603DaFZ KSFnUJU4njoh97DWD1dMbcXBqDoHvv+4hmxXjhxjAusYHw81GVKeUzpLOLLJi6O44kRf CIWA== Received: by 10.66.83.33 with SMTP id n1mr87325444pay.7.1342070411875; Wed, 11 Jul 2012 22:20:11 -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 se9sm3120525pbc.25.2012.07.11.22.20.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 22:20:11 -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: Wed, 11 Jul 2012 23:20:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl9NaGXV+EGrQCtv09EaLgGrz5uHYrOL7TkkwUFud+RYHlzg/X+6wGtbchBjl2TcTAdV0j1 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: Thu, 12 Jul 2012 05:20:13 -0000 On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe = wrote: >> Hi, >>=20 >> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >>>=20 >>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >>>=20 >>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh = wrote: >>>>>=20 >>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>>>=20 >>>>>> 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 >>>>>> 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. >>>>>=20 >>>>> 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. Certainly less hackish than not using them at all. Since dev0 = knows the layout of 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 from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. >>>>>=20 >>>> 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. >>>=20 >>> We are talking about the ivar interface. You are just = misunderstanding how it is used. >>>=20 >> yes I indeed did... silly, silly me :-) >>=20 > Actually, no. I wasn't that silly, neither was I misunderstanding > anything beside how *you* wanted it to be used, which is, I sorry to > say, unacceptable. The last thing I want is to pollute an interface > with a single-purpose, hand-crafted, bus. I was to just throw away all > that ivar stuff and go into hinted child configuration for now, > waiting for FDT... but of course, I figured out after a few hours that > hinted child attachment requires `bus_hinted_child' to be set in the > parent, as does bus_enumerate_hinted_children() / bus_generic_attach() > to explicitly pollute my code. All this stuff should be done > implicitly to support N:1 interfaces/client relationship. N > *independent* interfaces being provided by a single driver; of course, > I'm not even going back to require those interface being provided by > multiple drivers, it is already a dead end. >=20 > I am not even sure any driver in the tree provides more than one = interface... >=20 > For whatever reason, I am more and more thinking that this all > new-bus[0] stuff is *way* overkill, static, bloated at will, and > missing critical features; a huge PITA to use, for the intended > purpose. >=20 > /me pissed. >=20 > - Arnaud >=20 > [0]: damn, why is it even called "newbus", this stuff is 14 years old. > It really belongs to a museum, not production code... I'm sorry you feel that way. Honestly, though, I think you'll be more pissed when you find out that = the N:1 interface that you want is being done in the wrong domain. But = I've been wrong before and look forward to seeing your replacement. acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI = interfaces. Warner=