From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 14:10:29 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 E8EA21065670 for ; Tue, 24 Jan 2012 14:10:28 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 62FF58FC15 for ; Tue, 24 Jan 2012 14:10:28 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 2E061C4930; Tue, 24 Jan 2012 15:51:30 +0200 (EET) Date: Tue, 24 Jan 2012 15:53:41 +0200 From: Aleksandr Rybalko To: Oleksandr Tymoshenko Message-Id: <20120124155341.84a000f5.ray@dlink.ua> In-Reply-To: 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> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ben Gray , freebsd-arch@freebsd.org 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 14:10:29 -0000 On Mon, 23 Jan 2012 23:45:29 -0800 Oleksandr Tymoshenko wrote: >> >> 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. >> >> >> 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. >> >> Also if there is at least one APIMETHOD in interface one more >> function called 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, create way for device to explicitly register/deregister as an >> API "provider". If I understand patch correct, it will search for device every "API" call. Is it good? >> >> >> Comments, ideas?_______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to >> "freebsd-arch-unsubscribe@freebsd.org" -- Alexandr Rybalko aka Alex RAY