Date: Thu, 04 Dec 2003 14:43:02 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <XFMail.20031204144302.jhb@FreeBSD.org> In-Reply-To: <20031204.111430.78763615.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Dec-2003 M. Warner Losh wrote: > In message: <20031204174838.GH54398@funkthat.com> > John-Mark Gurney <gurney_j@efn.org> writes: >: M. Warner Losh wrote this message on Wed, Dec 03, 2003 at 17:58 -0700: >: > : Ideally, acpi.ko would contain two modules: 1 main acpi.kld module >: > : that was required and one optional madt.kld module that just contained >: > : madt.o and was optional. Then loading the module would succeed so >: > : long as the required 'acpi' module linked but if the optional 'madt' >: > : module failed to link, it would just be tossed. We don't really seem >: > : to be setup to do such things right now though. A more feasible model >: > : might be an acpi.a that contains acpi.ko and madt.ko and allow the >: > : kernel linker to handle foo.a by requiring the first .ko in the archive >: > : to link and having any additional .ko's be optional. This would work >: > : both for the acpi.ko/madt.ko case as well as bus attachments for device >: > : drivers such as a sym.a with sym.ko/sym_pci.ko/sym_cbus.ko, etc. >: > >: > I'm not sure I follow what you are saying here. You need to have >: > something to resolve the symbols that madt provides. >: >: 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 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? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031204144302.jhb>