Re: global data via module howto
- From: Roman Kurakin <rik@xxxxxxx>
- Date: Mon, 21 Aug 2006 15:10:39 +0400
M. Warner Losh wrote:
In message: <44E87CCD.30105@xxxxxxx>Module dependence is not the goal.
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);
WarnerI have a bit reversed case. In common case we have a driver for "bus" with many
: 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.
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: global data via module howto
- From: M. Warner Losh
- Re: global data via module howto
- References:
- global date via module howto
- From: Roman Kurakin
- Re: global date via module howto
- From: M. Warner Losh
- global date via module howto
- Prev by Date: Re: Aqcuiring full path to running process from outside the kernel
- Next by Date: [SoC] Jail Resource Limits
- Previous by thread: Re: global date via module howto
- Next by thread: Re: global data via module howto
- Index(es):
Relevant Pages
|
