From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 21 22:33:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 331D916A4E5 for ; Mon, 21 Aug 2006 22:33:20 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A068343D45 for ; Mon, 21 Aug 2006 22:33:19 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id E563D33C46; Tue, 22 Aug 2006 02:33:15 +0400 (MSD) Message-ID: <44EA3661.4090709@inse.ru> Date: Tue, 22 Aug 2006 02:40:33 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.12) Gecko/20060103 ASPLinux/1.7.12-1.5.1.1asp X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: "M. Warner Losh" References: <44E87CCD.30105@inse.ru> <20060820.220124.387191884.imp@bsdimp.com> <44E994AF.6040805@inse.ru> <20060821.105429.1649766410.imp@bsdimp.com> In-Reply-To: <20060821.105429.1649766410.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: global data via module howto X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 22:33:20 -0000 M. Warner Losh: >In message: <44E994AF.6040805@inse.ru> > Roman Kurakin writes: >: M. Warner Losh wrote: >: > In message: <44E87CChttp://comp.krovatka.ru/D.30105@inse.ru> >: > Roman Kurakin 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