From owner-cvs-all@FreeBSD.ORG Fri Dec 5 08:23:21 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A934016A4CE for ; Fri, 5 Dec 2003 08:23:21 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A3F243FE9 for ; Fri, 5 Dec 2003 08:23:18 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 18075 invoked from network); 5 Dec 2003 16:23:17 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 5 Dec 2003 16:23:17 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hB5GNDFn020369; Fri, 5 Dec 2003 11:23:13 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031204210904.GI54398@funkthat.com> Date: Fri, 05 Dec 2003 11:23:29 -0500 (EST) From: John Baldwin To: John-Mark Gurney X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: "M. Warner Losh" cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2003 16:23:21 -0000 On 04-Dec-2003 John-Mark Gurney wrote: > John Baldwin wrote this message on Thu, Dec 04, 2003 at 14:43 -0500: >> >: I don't know the acpi/madt interface, but why wouldn't a SYSINIT in >> >: madt that calls an acpi function with a struct of function pointers >> >: to notify acpi that it exists work? Then you don't have problems with >> >: acpi referencing madt's symbols and being required to load. acpi will >> >: get the pointers registered if it exists. >> > >> > This seems like a much more straight forward way to deal. acpi.ko and >> > madt.ko aren't unloadable at this point anyway (and any extra work >> > that the table would cause is so lost in the noise to make the >> > reloadable as to not be worth considering now). >> > >> > Function pointers or kobj are the same thing in this context, so >> > either could potentially be used. However, it isn't an interface that >> > needs to be 'stable to external users' so the normal reason to use >> > kobj applies much less to this case. >> >> I don't think you guys understand what madt.ko does. Also, what >> exactly are you proposing? Should madt.o be part of 'device apic' >> rather than acpi.ko? Basically, a patch (even a rough one) would go >> a long way in explaining what you mean. The MADT code already uses > > First off, madt isn't a module yet, but it shouldn't be hard to make > it.. Since it calls acpi functions, all you have to do it make sure > that it depends upon acpi, and it can be made it's own module. This > will prevent the link problems... For people that new/can use madt, > they just load the madt module which will autoload acpi, and for those > that don't, they continue to load acpi.. (or they can load both acpi > and madt from loader and the right thing will be done at kernel init > time)... The problem (which you didn't read in my mail I guess) is that the fact that madt.ko is in its own module shouldn't be user visible. The user should just say "load ACPI' and all the right magic should happen. > is thinking of) attachment... Then madt would become a device off the > acpi bus... If acpi can detect the presence of madt (self identifing > bus), it can create the device node for madt to attach too... if acpi > can't, then you use an identify function in the madt code to create > the device node off the acpi bus... new-bus doesn't exist yet when we probe CPUs. Again, you haven't actually looked at how this stuff works. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/