Date: Mon, 21 Aug 2006 10:54:29 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: rik@inse.ru Cc: freebsd-hackers@freebsd.org Subject: Re: global data via module howto Message-ID: <20060821.105429.1649766410.imp@bsdimp.com> In-Reply-To: <44E994AF.6040805@inse.ru> References: <44E87CCD.30105@inse.ru> <20060820.220124.387191884.imp@bsdimp.com> <44E994AF.6040805@inse.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <44E994AF.6040805@inse.ru>
Roman Kurakin <rik@inse.ru> writes:
: M. Warner Losh wrote:
: > In message: <44E87CCD.30105@inse.ru>
: > Roman Kurakin <rik@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.
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.
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060821.105429.1649766410.imp>