From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 22 13:47:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D440016A420 for ; Wed, 22 Mar 2006 13:47:40 +0000 (UTC) (envelope-from zazubrik@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C7CD43D45 for ; Wed, 22 Mar 2006 13:47:40 +0000 (GMT) (envelope-from zazubrik@mail.ru) Received: from [195.149.104.96] (port=47263 helo=[10.13.66.8]) by mx3.mail.ru with esmtp id 1FM3gZ-000MYV-00 for freebsd-hackers@freebsd.org; Wed, 22 Mar 2006 16:47:39 +0300 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1142510785.36931.43.camel@timon> References: <1142506792.36931.25.camel@timon> <200603161235.24124.hackers@dino.sk> <1142510785.36931.43.camel@timon> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26A95C2F-FE0A-4434-B164-A24BA2E5D950@mail.ru> Content-Transfer-Encoding: 7bit From: Artem Ignatiev Date: Wed, 22 Mar 2006 16:47:36 +0300 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.746.3) Subject: Re: newbus questions 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: Wed, 22 Mar 2006 13:47:40 -0000 On 16.03.2006, at 15:06, Artem 'ZaZooBred' Ignatiev wrote: > On Thu, 16/03/2006 12:35 +0100, Milan Obuch wrote: > >> .... >> >>> 1. How to create the bus itself, and properly describe its >>> interfaces? >>> skeletons of bus-driver and frontend-drivers would be a GREAT help. >> >> Being far from everything knowing hacker, I just can help with >> what I found >> when working on something totally unrelated. >> First you need to write .m file describing your methods - they are >> class >> description, kind of. There are couple of them - maybe PCI analogy >> (pci_if.m >> and pcib_if.m) could help a little to understand their role. Then >> you can use >> these methods in your device_method_t array describing your >> device. Actually, >> these definitions are something like software bus between parent >> and child >> device. And maybe you could get some clue looking at bktr driver, >> which could >> be somehow related to your are of interest. > > Yes, I've got some clearance in how that _if.m files are > written, but bktr driver is too complex for me to understand how the > things are done right now. I'll look at it again, though, maybe I > could > understand the logic of how such things are done, when I could clearly > separate generic logic from implementation of particular hardware > driver. Okay, now I have got the bus device, the child device. My current trouble is that I want bus driver to provide some methods to child drivers. So I created saa_bus_if.m file, declared some methods there, made implementation in bus driver and added them using DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl), and added the saa_bus_if.c to child driver SRCS. Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it works just as expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent (subdev), ...) inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to generic function (which returns ENXIO) rather than pointer to my implementation. The questions are: Am I going the Right Way(tm) when exporting functions to child drivers like that? If yes, what I must do in order to get the real implementation, not the default one? If no, what is The Right Way(tm)? Thanks in advance.