iokit

I am trying to write a Cocoa program which detects iPods connected to Mac OS. I am listening to NSWorkspaceDidMountNotification and NSWorkspaceDidUnmountNotification for the USB device mount and unmount notifications. I can get the device path of the mounted device using NSString *path = [[notif userInfo] objectForKey:@"NSDevicePath"]; but I also need t know the Device Id, Vendor Id, Product Id etc to check whether the mounted device is an iPod. I think the way forward is IOKit. But I have a feeling that it for low level programming. Is there any other way to find these? Also, if it is IO kit

Is there a reliable, quick, deterministic way (i.e. not a benchmark) to check whether the system drive Mac OS X is on is a Solid State Drive? Is there any other indicator how well disk handles parallel access? I'm trying to adjust number of threads that my program is going to use for disk-bound operations. I'm not interested in raw speed or seek time, only which type of access – serial or parallel – is faster for the drive. I don't expect users of my program to use iSCSI or RAID. SSD is my focus, anything else is nice-to-have. Device Characteristics of IOAHCIBlockStorageDevice contains this

We're working on a project with my colleagues which involves using a lot of private and non official code. This is not intended for AppStore use. The first and only requirement we have is to not use jailbreak. First of all, UDID or OpenUDID or any other solutions don't work here and they're not expected to. We've done a lot of background research and tests, starting with trying to get the IMEI , ICCID, IMSI and the Serial Number programatically. None of the above methods work with iOS 7 and above without jailbreak. We've also spent a couple of months to play with IOKit framework using the

I've written a kext for OS X that implements a USB-based framebuffer using (IOKit) libusb and jpeglib. Both of those are dylibs, and for some reason they won't link properly in XCode, and the OS won't resolve the dependencies when it attempts to load the kext. The background of this whole thing is that Samsung makes an LCD picture frame that can act as a second monitor; the only problem is that it's not DisplayLink or any other known protocol -- the Windows-only driver spits out a custom header and each frame is encoded as a JPEG and sent to the device. My implementation does that for OS X,