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

John-Mark Gurney gurney_j at efn.org
Fri Dec 5 11:03:13 PST 2003


John Baldwin wrote this message on Fri, Dec 05, 2003 at 11:23 -0500:
> 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.

Well, now that you restate it, it's more clear.  I got confused with
your talking about linking issues, and other stuff, not just that issue.

I was going to say, why don't you just call
linker_load_module("madt.ko", NULL, NULL, NULL, NULL) from acpi and
ignore the return code.  Then if the module exists, it's loaded, if it
doesn't, nothing changes...

But this is problematic since SI_SUB_KMEM is significantly earlier than
SI_SUB_KLD..

> > 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.

I realized that shortly after I sent off the email that we might be a
bit earlier than the vm subsystem and friends have been setup for newbus.

Ok, now I'm completely confused, why is ACPI mentioned sooo much when
the apic code that madt uses doesn't reference ACPI??

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


More information about the cvs-src mailing list