You can build your own jump table. You could provide a library that you link
in to each of your kexts that provides the functions that your library
provides. The first time any of your function stubs gets called,
attempt to resolve all of the functions.
Try to find your tracing 'library' kext using IOService::getMatchingServices()
or IOService::ServiceMatching().
If you don't find it, just do nothing or return an appropriate error code.
If you want to potentially wait a few seconds for it to load, you can use
IOService::waitForService().
If you locate your class, use OSMetaCast to cast it into the class of your
tracing 'library'.
match = IOServiceServiceMatching("MyTracingLibraryClass");
service = IOService::waitForService(match, &t);
my_library = (IOService*)service->metaCast("IOService");
if (my_library)
return ((MyTracingClass*)my_library)->TracingStart();
else
return ERROR;
For this last manual cast, you might need to play with OSDynamicCast or
metaCast() to get it to do what I'm implying you can do.
You'll need to do something to your Tracing Library kext to force it to
load at every startup, regardless of whether anybody is referencing it or
not. Oh, you probably need to figure out a way to cause the kextloader to
realize that you have obtained a pointer to the class if you're going to
use this method... otherwise the kernel may unload your Tracing Library kext
while you still have pointers into memory where it previously was loaded.
I don't use this exact method, but I have done something similar to this
in the past... everything but that last manual cast.
--Steve
On Mon, Sep 19, 2005 at 01:24:54PM -0500, Jim Hunter wrote:
> We have developed a lightweight kernel tracing facility, and intend
> future releases of our drivers and other kernel code to support
> tracing without the need to recompile. Those future drivers would
> therefore make calls to a handful of external "STCTraceXXX"
> functions. Those functions are implemented in a separate STCTrace
> kext, which we would prefer to avoid installing along with our
> drivers. This requires some way to satisfy the linker references to
> the tracing functions in our drivers when the trace kext is not
> installed.
>
> The best method we have thought of so far is to bundle a "dummy"
> tracing kext as a PlugIns kext within each of those drivers, for the
> purpose of defining "do nothing" versions of the tracing functions.
> Each of those dummy kexts would implement the same "service" (as
> defined by a CFBundleIdentifier) that the real tracing kext does, and
> that our drivers would call out as a dependency in their
> OSBundleLibraries dictionaries. We would use IOProbeScore to ensure
> that the real tracing kext, if present, gets loaded over any of its
> dummy versions.
>
> A cleaner alternative, if possible, would be some sort of "weak
> linking" scheme, in which the references to the tracing functions are
> *not* required to be satisfied by the kext loader, with the
> expectation that their symbols would be assigned an address of 0 if
> not found. This is my notion of how weak linking works for user code,
> but I don't know if such a scheme works for kernel code.
>
> Can such a "weak linking" scheme be made to work for kernel code? Can
> anyone think of a better approach than our "dummy PlugIn kexts" scheme?
>
> Thanks,
> Jim.
>
> ================================
> Jim Hunter - Small Tree Communications
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-drivers mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
