global data via module howto

[Roman Kurakin]

M. Warner Losh wrote:
> In message: <44E87CCD.30105 at inse.ru>
>             Roman Kurakin <rik at inse.ru> writes:
> :     I have the following problem:
> : module A
> :     int x;
> : 
> : module B
> :     extern int x;
> : 
> :     Module A is loaded, module B can't be loaded cause of unknow 'x'.
> : What should I do to make x global?
>
> Better to make module B depend on module A.  Making it global is
> generally a bad idea.
>
> in module A:
> MODULE_VERSION(A, 1);
>
> In module B:
> MODULE_DEPEND(B, A, 1, 1, 1);
>   
Module dependence is not the goal.
> Warner
>
> : PS. I am working on porting irda support for USB devices from NetBSD.
> : The current model consists of two layers hw and sw. hw is the usb device
> : driver. sw is some software layer the same for all device and it is a
> : child on top of hw 'bus'. To make this working I need to add
> : DRIVER_MODULE for each 'bus'. To make sw independent from the
> : bus I need to export _driver and _class structures and put DRIVER_MODULE
> : in 'bus' code instead of 'child'.
>
> Are you sure that you need to do this?  I'm pretty sure that you can
> create a base class irdabus and then derive all the hw modules that
> implement irdabus from than and all the children will automatically
> probe.  No need to export the driver/class structures.
>   
I have a bit reversed case. In common case we have a driver for "bus" 
with many
consumers. And we have children that declares itself via DRIVER_MODULE.
If child could work on several buses it declares itself several times 
one for each
bus. In my case I have several drivers that could be treated as bus 
driver for the
same child:

 -----------USB------------
 |            |           |
ustir       uirda     smth_else
 \            |           /
  ---------irframe--------

Imagine, if the network interface was implemented as a child of every 
network
adapter. This is the same. In common case I'll put DRIVER_MODULE in a child
for each bus and recompile after adding a new one. In this case I do no 
want to
recompile the child for every new "bus" since child do not depend on 
such "bus"
- it is the same for all. So we may call this a pseudo-device with 
unknown list
of buses. I know, I could implement this other way, but I just want to 
play with
newbus a bit and the original NetBSD driver was implemented this way.

rik
> Warner
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>