cvs commit: src/sys/i386/i386 machdep.c

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/