Post

Replies

Boosts

Views

Activity

The launchd launches LaunchDaemons and the system extensions after the LaunchAgents when FileVault is enabled
On the systems with FileVault enabled, the LaunchDaemons and system extensions start after the first user login. But I expect that they will launch before LaunchAgents and other user services. When I use endpoint security as a LaunchDaemon, it launches after some LaunchAgents in 100% of cases. When I use endpoint security as a system extension with the flag NSEndpointSecurityEarlyBoot, it launches after some LaunchAgents in 90% of cases. This behavior looks like a system issue because the flag NSEndpointSecurityEarlyBoot should guarantee an earlier start than other services.
6
0
1.5k
Feb ’23
Optimizing I/O operations in kernel (VFS)
Hey everyone, I'm currently working on developing a kernel extension (kext) for the custom file system on macOS. I opted for a kernel extension due to its potential for higher performance compared to using FileProvider. However, during development, I've noticed a significant performance bottleneck related to synchronous I/O operations within the VFS subsystem. It appears that all I/O operations in the macOS kernel, such as vnop_read/vnop_write (sock_receive/sock_send), are executed synchronously. (https://forums.swift.org/t/task-safe-way-to-write-a-file-asynchronously/54639/7) For example, the Linux kernel supports asynchronous I/O operations, which utilize struct file_operations.read_iter/write_iter. This discrepancy in implementation leads to a considerable performance gap, with macOS performing approximately 8-15 times slower than Linux implementation. Given this performance difference, I'm reaching out to seek advice and insights from the community. Are there any known strategies or best practices for improving the performance of kernel extensions related to file systems on macOS? Any guidance or suggestions on how to optimize the performance of file system operations on macOS kext would be greatly appreciated. Thank you in advance for your assistance!
0
0
498
Mar ’24