Re: newbus questions
- From: John-Mark Gurney <gurney_j@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 22 Mar 2006 11:23:53 -0800
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
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
description, kind of. There are couple of them - maybe PCI analogy
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
these definitions are something like software bus between parent
device. And maybe you could get some clue looking at bktr driver,
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
understand the logic of how such things are done, when I could clearly
separate generic logic from implementation of particular hardware
Okay, now I have got the bus device, the child device. My current
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
in bus driver and added them using
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
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
inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to
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
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."
freebsd-hackers@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Re: newbus questions
- From: Artem Ignatiev
- Re: newbus questions
- Prev by Date: Re: dlopen() and dlclose() are not MT-safe?
- Next by Date: Re: dlopen() and dlclose() are not MT-safe?
- Previous by thread: Re: newbus questions
- Next by thread: Re: newbus questions