Date: Tue, 22 Aug 2006 02:40:33 +0400 From: Roman Kurakin <rik@inse.ru> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org Subject: Re: global data via module howto Message-ID: <44EA3661.4090709@inse.ru> In-Reply-To: <20060821.105429.1649766410.imp@bsdimp.com> References: <44E87CCD.30105@inse.ru> <20060820.220124.387191884.imp@bsdimp.com> <44E994AF.6040805@inse.ru> <20060821.105429.1649766410.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh: >In message: <44E994AF.6040805@inse.ru> > Roman Kurakin <rik@inse.ru> writes: >: M. Warner Losh wrote: >: > In message: <44E87CChttp://comp.krovatka.ru/D.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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44EA3661.4090709>