kernel-extension

I would like to retrieve the path of a process from a PID in a kext, like so: Get name from PID? However, sys/proc_info.h and libproc.h are not available anymore (afaik). Is there any other way to retrieve proc_info for a process struct proc *p from a kext? The function that is supposed to return a process's main executable's vnode , proc_getexecutablevnode() is in the private KPI, which is only available to kexts published by Apple. The information it relies on is supposedly stored in the p_textvp field of struct proc , which once again is not part of the public ABI - Apple can choose to

I have written a device driver kext for a hot-plug SCSI device, based somewhat on Wagerlabs code (using a driver-user client-application model) and everything works. The only remaining concern is that the driver appears not to be consistently freed, especially if the application crashes. For example, when I try to unload the kext, even with the device disconnected and the application closed, there are still outstanding instances of the driver and user client (with the driver generally outnumbering the user client). I have logging in the driver functions like free() , and when I shut down the

So we have a certificate that allows us to sign kexts, but when we run > sudo kextload friendly.kext, it fails and we sign the kext we want, and to prove it's signed, here's some diagnostic output: 👉 codesign --verify -vvvv friendly.kext friendly.kext: valid on disk friendly.kext: satisfies its Designated Requirement 👉 spctl -a -vvvv friendly.kext friendly.kext: accepted source=Developer ID origin=Developer ID Application: Friendly Corporation /Library/Extensions 👉 codesign -dvvv friendly.kext Executable=/Library/Extensions/friendly.kext/Contents/MacOS/friendly Identifier=com.friendly.friendly

I am attempting to communicate with a rather specific USB device and developing both Windows and Mac code to do so. The device is a USB device with a HID interface (class 3) with two endpoints, an interrupt input and an interrupt output. The nature of the device is such that data is sent out from the device on the input endpoint only when data is requested from the host: the host sends it data which the device responds to on its input interrupt endpoint. Getting data to the device (a write) is much more simple... The code for Windows is rather straight-forward: I get a handle to the device and