Re: global data via module howto

M. Warner Losh:

In message: <44E994AF.6040805@xxxxxxx>
Roman Kurakin <rik@xxxxxxx> writes:
: M. Warner Losh wrote:
: > In message: <44E87CChttp://comp.krovatka.ru/D.30105@xxxxxxx>
: > Roman Kurakin <rik@xxxxxxx> 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.

Right. That's how symbols are visible to other modules.

: >
: > : 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.

I think I must have not been clear before. I thought gave a solution
to this that doesn't require a new DRIVER_MODULE for each new device.
Let me try again.

I'd hoped to say make ustir, uirda and smth_else all subclasses of a
irbridge class, just like we do for pci and cardbus today. Then
irframe would attach to irbridge and you'd only need to list
DRIVER_MODULE lines once. This isn't a reversed case at all. It is
actually quite common, but has been 'papered over' until now via
multiple DRIVER_MODULE lines, except in the case of pci/cardbus[*].

I can provide more details on actually doing this. Right now I'm
doing something similar for all the iic bridges that we have in the
kernel. The number of devices with iicbus children is way too large
and we can eliminate that issue via the technique. I'd be happy to
flesh it out a bit, or provide you with sample code if you need that.


If you have a sample, it should help me a lot. Thanks.

Warner

[*] There's still pci and cardbus DRIVER_MODULE lines in many drivers,
but they are almost not needed. There's a newbus bug that I've not
had the time to track down that prevents kldload from working
competely correctly in some cases (like when loading the cardbus
module). Once I get that fixed...


If I hit this problem for my case, I'll be glad to help to fix it.

rik

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: global data via module howto
    ... In common case we have a driver for "bus" ... If child could work on several buses it declares itself several times ... In common case I'll put DRIVER_MODULE in a child ...
    (freebsd-hackers)
  • Re: global data via module howto
    ... I am working on porting irda support for USB devices from NetBSD. ... In common case we have a driver for "bus": ... : If child could work on several buses it declares itself several times: one for each ...
    (freebsd-hackers)
  • Re: global data via module howto
    ... : extern int x; ... : DRIVER_MODULE for each 'bus'. ... In common case we have a driver for "bus" with many ... If child could work on several buses it declares itself several times one for each ...
    (freebsd-hackers)
  • Re: newbus flaw
    ... > the bus's list of child devices. ... > already exists on the bus, or for the module's event handler to unlist ... For example, in my adv717xa driver, part of the zoran driver, I do the ...
    (freebsd-arch)
  • Re: usbd does not use detach
    ... "M. Warner Losh" wrote: ... > the device is still present on the bus. ... Another factor that aggravates this is that in some cases, the driver ... I haven't looked at the code extensively, but I believe the GEOM ...
    (freebsd-current)