From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 05:18:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3591A106564A; Mon, 9 Jul 2012 05:18:00 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 90E658FC08; Mon, 9 Jul 2012 05:17:59 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2069602wib.13 for ; Sun, 08 Jul 2012 22:17:53 -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=/Fgc51bagA4OIHukFXEdz+x40tkf/RC5w8RhoUsBCTE=; b=cTV3smi106Ka69hyE9BE8LW+dp+EQ8QU47IcgrAP+ptXMBwonco1PVD3N9hOhmNNej 2uJUVs6JEeTiXP8s9XFHEwZXuWSVvN31s52J8xIhPqFpKf/vu+dGB3ti3Wz6uq4/eKvC Vx9trLXww4UxoshkOoabz/NGe+5hAOpgR50QY2hGsbnOjY5LVxn+GoKY5W4EU/gmtsyV utNIuWrLdLD7Cyvr/eLFMv4df8K3o78jJ7EaM0pdfh4QnhviitKU0esWYeeG92j0IZQr GMgmHoZN6uau4HV+bDxRLRFPTd3rwl0zcpwJByF0KvF04sf312kCImFMDVrqbfDvQvtI HUBQ== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr26490361wib.3.1341811072926; Sun, 08 Jul 2012 22:17:52 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 22:17:52 -0700 (PDT) In-Reply-To: <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Mon, 9 Jul 2012 01:17:52 -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 05:18:00 -0000 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 o= ne >>>>>> 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 w= ay >>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>> userland). So, it would have been nice if ivar had been per-interfac= e, >>>>>> not global and unique to one device. >>>>> >>>>> There's one pointer for the ivars. The bus code gets to determine wh= at 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 d= oesn'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 valu= es. If the Ivar keys don't overlap, then there's no problems at all. Cert= ainly 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. I= t 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. >>> >> 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 h= ow it is used. > yes I indeed did... silly, silly me :-) - Arnaud