| Thank you. That did it, with a bit of extra work on my part. I am posting the following so that it stays in the archive if anyone else needs it.
The build instructions provided in the "Building your first kernel" appear to be out of date (at least the ones I have). The differences are as follows: - it gets built with gcc 4.0, so the "gcc_select 3.3" is not necessary. - kextsymboltool needs to be compiled as "gcc kextsymboltool.c -o kextsymboltool -I ../CCTOOLS_DIR/include/ or it will complain about a missing header file.
After building the kernel, the necessary include files (such as the version of kdebug.h which has all the private data structures needed) can be found in: XNU_DIR/bsd/ so just adjust the fs_usage Makefile include paths accordingly. Also, the following C options need to be added: -D__APPLE_API_UNSTABLE -D__APPLE_API_PRIVATE -DPRIVATE
And that's about it.
On May 22, 2007, at 6:30 PM, Terry Lambert wrote: On May 22, 2007, at 11:47 AM, Thomas Inskip wrote: I am trying to build fs_usage on MacOS X 10.4.9, but it won't compile because some types, such as kbufinfo_t, kd_threadmap, and kd_buf. The included makefile sets the header search paths to /System/Library/Frameworks/System.framework/PrivateHeaders and /System/Library/Frameworks/System.framework/PrivateHeaders/bsd, which are not available with the standard Xcode distribution. Surprisingly the compiler does no complain about not being able to find any header files, so it must be finding the wrong ones elsewhere, presumably.
Could someone please tell me where I can get System.framework/PrivateHeaders? I have found past threads to this regard in the archives, but unfortunately no solutions.
You have to build your own xnu to get them.
These header files describe the contract between the kernel and the code that you promise you will recompile each time you recompile the kernel, so that the data interfaces described by the structures and other data objects in those headers will match up between them.
Because of this, they are considered SPI (System Private Interfaces).
If the reason you are doing this is to use the code as the basis of your own tool, the normally suggested route is to write code to talk to the system supplied tool instead. This isolates your code from changes which could otherwise cause it to break, if you were to use the interfaces directly, yourself.
-- Terry
|