Date: Fri, 05 Dec 2003 11:23:29 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: John-Mark Gurney <gurney_j@efn.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <XFMail.20031205112329.jhb@FreeBSD.org> In-Reply-To: <20031204210904.GI54398@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.20031205112329.jhb>