Raising a thread from the dead, but for folks having issues with os_log and KEXT. For some reason I can't add an URL directly, but try https://dmaclach.medium.com/logging-in-kernel-extensions-kexts-on-macos-b558472a9d92 for info. Filed as FB9069234 for better documentation on os_log.

Oh.. forgot to mention: keyOSBundleLibraries/key dict keycom.apple.kpi.bsd/key string17.0.0/string keycom.apple.kpi.iokit/key string17.0.0/string keycom.apple.kpi.libkern/key string17.0.0/string keycom.apple.kpi.mach/key string17.0.0/string keycom.apple.kpi.unsupported/key string17.0.0/string /dict

Thanks Quinn. Apologies if this is a dumb question, but for someone who hasn't done a lot of kernel work, how would one determine that task_policy_get is not a usable KPI? I must admit that since it appeared in the kernel headers and in documentation - https://developer.apple.com/documentation/kernel/1537778-task_policy_get?language=objc that I kind of thought it was legit. So what I am doing is working on a FUSE based file system. So I have a process (the client) in userspace accessing a file through fuse (a kernel extension) which is calling back into userspace file system (the filesystem). Communication between the kext and the file system is done via read/write. For some reason on the M1 some of the client processes seem to be getting a high qos number and I think we may be getting some lock inversion with the filesystem which basically locks up the client/filesystem until the filesystem times out and everything errors. FWIW This system has been working fine for some time on Intel. Basically I was just trying to run some experiments to see if I could boost the qos of the filesystem temporarily and was hoping to use task_policy_get/set to do it. Yes I'm waving my hands wildly a bit here, but any other ideas would be appreciated. Cheers, Dave

Thanks again Quinn.. Sigh.. apparently my google-fu is weak in that I couldn't find that tech note previously. The pointer (and python script) is greatly appreciated. I’m going to encourage you to look at doing this with a File Provider extension. FUSE relies on the VFS KPI and, while that hasn’t been formally deprecated, Apple has announced that we plan to replace and then deprecate, and then eventually drop support for, all KPIs. Indeed, we’ve already been through this process for NKEs. Yes... I have chatted with the File Provider team, and they are not supporting the scale of what we are doing. Unfortunately their current design is for a pretty specific set of use cases (last I checked). A high QoS value is not at all unusual. Ideally you’d do your IPC using a mechanism that supports QoS donation, but this is hard when running inside the kernel. Our current IPC mechanism to the file system is uio - read/write. Do you have any pointers towards a mechanism inside the kernel that support QoS donation? Use a spin dump to see exactly where things are getting blocked. Use the System Trace instrument to see which threads are being scheduled at which priority. Yeah. Been playing with spin dump and have some ideas. That's where I found the high QoS numbers. I hadn't thought of trying system trace. Cheers, Dave

Hey Quinn.. the 11.3 b8 release notes had a blurb about The Kernel Debug Kit (KDK) now runs on Macs with Apple Silicon. (73848762) but it's disappeared from the RC release notes, and the 11.3 b8 release notes appear to have been removed. I "assumed" that this meant that kernel extension variants were usable with Apple Silicon. The docs with the KDK still say it's intel only, but the KDK is shipping with development and kasan kernel variants. Is there anyway to get a development kernel variant working on a M1 mini? I tried just for fun and ran into problems with: sudo kmutil install --volume-root /Users/dmaclach/livemount --update-all -v -a arm64e Not rebuilding KC for arch: 'arm64e' kmutil done

Here's another potential solution that is a simple command line app: https://github.com/dmaclach/crashdump

Sigh... ok so it turns out I forgot to mention that I was running my sample code from within Xcode, so the debugger was in play. Apparently having lldb in the mix messes with the signal handling (not a huge surprise, but still annoying). You are correct that it works fine without the debugger in the mix. I'll update the feedback accordingly. Thanks (somewhat embarrassed :) ) Dave

Your problem is here: https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp#L991 Turns out that the sanitizers use puts to figure out if they have installed themselves early enough in the launch process. I was running into a similar issue except I was trying to override __sanitizer_report_error_summary which according to the headers I should be able to override. https://reviews.llvm.org/D144830

I believe you could use: NSMorphology.userMorphology.grammaticalGender Note that you can only set gender through the system preferences if your primary language is a strongly gendered language (e.g. French), but once it is set you can switch back to English and it is still accessible. You can then see it using defaults read com.apple.morphology

Found this msdos file system, but I wouldn't say it's extensively documented :)

We are seeing this as well and seems to be happening on iOS 18.5 beta 1. Going to test on beta 3 asap. FB17176757