From owner-cvs-src@FreeBSD.ORG Thu Dec 4 13:09:12 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9006116A4CE for ; Thu, 4 Dec 2003 13:09:12 -0800 (PST) Received: from mail7.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EF3343FE5 for ; Thu, 4 Dec 2003 13:09:06 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 22324 invoked from network); 4 Dec 2003 21:09:05 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail7.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Dec 2003 21:09:05 -0000 Received: from hydrogen.funkthat.com (knwluz@localhost.funkthat.com [127.0.0.1])hB4L94gP090299; Thu, 4 Dec 2003 13:09:05 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id hB4L94Jt090298; Thu, 4 Dec 2003 13:09:04 -0800 (PST) Date: Thu, 4 Dec 2003 13:09:04 -0800 From: John-Mark Gurney To: John Baldwin Message-ID: <20031204210904.GI54398@funkthat.com> References: <20031204.111430.78763615.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: "M. Warner Losh" Subject: Re: cvs commit: src/sys/i386/i386 machdep.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 21:09:12 -0000 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)... > a SYSINIT to register its enumerator switch table with the 'device > apic' code. So MADT already provides function pointers to the > apic code as it were. However, those functions call other functions > in the APIC code to register the actual APIC devices. How does > that interface work? Esp. how does it work any better than the current > hack, and esp. how does it work better than a slightly more intelligent > kernel module system? One way would be to make acpi a newbus (which is what I believe Warner 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... This method would also eliminate the enumerators struct you have since it would just call the methods of it's children, and the probe code would be assumed to call before the device gets attached. hmmm... We don't have a cpu device to hang some of the apic code off of... Which would be logical since we don't do apic code unless the cpu has a built in APIC... But I guess nexus would be fine... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."