Date: Wed, 22 Mar 2006 11:23:53 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Artem Ignatiev <zazubrik@mail.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: newbus questions Message-ID: <20060322192353.GB35129@funkthat.com> In-Reply-To: <26A95C2F-FE0A-4434-B164-A24BA2E5D950@mail.ru> References: <1142506792.36931.25.camel@timon> <200603161235.24124.hackers@dino.sk> <1142510785.36931.43.camel@timon> <26A95C2F-FE0A-4434-B164-A24BA2E5D950@mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Artem Ignatiev wrote this message on Wed, Mar 22, 2006 at 16:47 +0300:
> 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 <something>_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.
You should only add the saa_bus_if.h to the child driver.. the if.c
file is for the part that implementes the bus.. be it one driver, or
part of the kernel... I'm surprised you aren't getting duplicate
symbols...
> 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)?
Most of the drivers have code in the default, that will reapply the
function to the parent, so you don't have to do the device_get_parent
in your driver.. They also implement their own lower case wrappers
too...
This very well could be due to the fact that you're including your
interface twice, and that the second time isn't seeing the same cache
entry in the KOBJ cache..
Why are you compiling the _if.c twice? If this was to get around
undefined symbols at module load time, I found that you need to add a
MODULE_DEPEND to the module the provides the symbol...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060322192353.GB35129>