From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 07:45:32 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC1E51065670 for ; Tue, 24 Jan 2012 07:45:32 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9538FC12 for ; Tue, 24 Jan 2012 07:45:32 +0000 (UTC) Received: from [24.87.53.93] (helo=[192.168.1.116]) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Rpb4I-0003HZ-O2; Mon, 23 Jan 2012 23:45:27 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <4F1A3B58.7040001@freebsd.org> Date: Mon, 23 Jan 2012 23:45:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> <4F1A3B58.7040001@freebsd.org> To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1084) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote: > On 20/01/2012 5:43 PM, Warner Losh wrote: >> >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >>> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up? >> >> Sure there is: you can do it by name. I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer. My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t. I wonder why we can't do that here? > > I've been thinking about it recently in regard to GPIO subsystem. > And the same issue appeared during OMAP code import: there are at least > two subsystems that are used by the rest of the drivers. Ben's suggested > following solution: define kobj interface if_SUBSYTEM.m and then > provide API call in form: > > int omap_prcm_clk_enable(clk_ident_t clk) > { > device_t prcm_dev; > > prcm_dev = devclass_get_device(devclass_find("omap_prcm"), 0); > if (prcm_dev == NULL) { > printf("Error: failed to get the PRCM device\n"); > return (EINVAL); > } > > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); > } > > So it might make sense to create some kind of upper-level API for > defining this kind of subsystems' APIs since every implementation > would duplicate a lot of code: look for instance of specific > devclass, check if it exists. Not sure how to do it at the moment > though. [...] Content analysis details: (-4.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list Cc: Ben Gray Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:45:32 -0000 On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote: > On 20/01/2012 5:43 PM, Warner Losh wrote: >>=20 >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >>> The second problem is that there's currently no way to express a = dependency between two devices other than a parent-child relationship. = I would be interested to learn why this appears to be so uncommon that I = could not find any discussion of such a feature. Has it really never = before come up? >>=20 >> Sure there is: you can do it by name. I wrote a driver that attached = to the ISA bus, but also needed to talk to the ppbus that was attached = to the printer. My solution was to have a post-attach name-lookup so = that it could then call methods on the other driver's device_t. I = wonder why we can't do that here? >=20 > I've been thinking about it recently in regard to GPIO subsystem. > And the same issue appeared during OMAP code import: there are at = least > two subsystems that are used by the rest of the drivers. Ben's = suggested > following solution: define kobj interface if_SUBSYTEM.m and then > provide API call in form: >=20 > int omap_prcm_clk_enable(clk_ident_t clk) > { > device_t prcm_dev; >=20 > prcm_dev =3D devclass_get_device(devclass_find("omap_prcm"), = 0); > if (prcm_dev =3D=3D NULL) { > printf("Error: failed to get the PRCM device\n"); > return (EINVAL); > } >=20 > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); > } >=20 > So it might make sense to create some kind of upper-level API for > defining this kind of subsystems' APIs since every implementation > would duplicate a lot of code: look for instance of specific > devclass, check if it exists. Not sure how to do it at the moment > though. I tinkered a little bit with this idea and here is what I've come up = with so far: http://people.freebsd.org/~gonzo/patches/horizontal-api.diff this patch adds one more available declaration to .m files: APIMETHOD In addition to usual kobj method declaration one more function is = generated. This function gets first device in devclass with the same name as = declared interface and uses it as object for respective method call.=20 Also if there is at least one APIMETHOD in interface one more function = called=20 XXXX_available() is generated. It returns 1 if there is device of = required devclass. Usage example: int maxpin; printf("GPIO available: %d\n", gpio_available()); if (gpio_available()) { gpio_pin_max(&maxpin); printf("GPIO pins: %d\n", maxpin); } Possible improvements: instead of using devclass for identifying kobj,=20= create way for device to explicitly register/deregister as an API = "provider".=20 Comments, ideas?=