From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 03:47:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C48106566B; Thu, 12 Jul 2012 03:47:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6158FC0A; Thu, 12 Jul 2012 03:47:51 +0000 (UTC) Received: by lbon10 with SMTP id n10so3307323lbo.13 for ; Wed, 11 Jul 2012 20:47:50 -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=Ykhiy4BXcrqg714iHPrnFmeaf2/wIiragN6AFheEyV0=; b=l4vLuz8Kl4iBK4NMEn+ZryNvZ5cJMmAeah7WRf9oVxVqofUyxnJHrgGxJeixY02a3o Pi1xb3DfElMay7DrKrb/dIsBjlDBLNAlkaTVfwGKLHz6AnFMoqfYVohEYzVMXRQGAWL0 +yDrzZrydLtOo7SwSlW2gyk6X1JGhQkqnXV5copY7Ae9Y8ILs4Zy6T0Awc4NTQKa3Jv3 27DzZYA6N2FtKCRpsfD4FI4o1dOjJvWzCod2sJ3NiZHg6Reebkh6g1FMXdG4HCeVqlR0 BPQK3/5P+4l3pVEy0yGwaLQ4fkyQVjCfWKhDE2zQvUF82aG85xa13wFrsInCgug48EkY cSjw== MIME-Version: 1.0 Received: by 10.152.132.40 with SMTP id or8mr51802446lab.24.1342064870717; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) In-Reply-To: References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Wed, 11 Jul 2012 23:47:50 -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-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: Thu, 12 Jul 2012 03:47:52 -0000 Hi, On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >> >> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >> >>> 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-interfa= ce, >>>>>>> not global and unique to one device. >>>>>> >>>>>> There's one pointer for the ivars. The bus code gets to determine w= hat the ivar looks like, because the interface is totally private to the bu= s. 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. >>>>>> >>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs t= o >>>>> 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 val= ues. If the Ivar keys don't overlap, then there's no problems at all. Cer= tainly less hackish than not using them at all. Since dev0 knows the layou= t 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 thos= e from B in the right part. Apart from the coordination of Ivar numbers, a= s 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. >> >> We are talking about the ivar interface. You are just misunderstanding = how it is used. >> > yes I indeed did... silly, silly me :-) > 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. I am not even sure any driver in the tree provides more than one interface.= .. 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. /me pissed. - Arnaud [0]: damn, why is it even called "newbus", this stuff is 14 years old. It really belongs to a museum, not production code...