Date: Thu, 4 Dec 2003 13:09:04 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: John Baldwin <jhb@FreeBSD.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <20031204210904.GI54398@funkthat.com> In-Reply-To: <XFMail.20031204144302.jhb@FreeBSD.org> References: <20031204.111430.78763615.imp@bsdimp.com> <XFMail.20031204144302.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031204210904.GI54398>