First off, I want to start with a clarification here: We are in a logical deadlock. The kernel dispatches a probe command before UserCreateTargetForID returns, and both of our methods for handling this command result in a permanent hang of the registration process: Calling UserCreateTargetForID means please create the storage stack for this target. Returning from it means I've finished creating the storage stack for this target. I'm not sure how far up the stack you'll actually get, but it's conceivable that we'd get all the way through partition map interpretation and (possibly) volume format detection BEFORE UserCreateTargetForID returns. You're basically guaranteed to get I/O request before UserCreateTargetForID returns. [1] I think the upper levels of the SAM stack prevent this by returning from state before calling registerForService on their IOStorage family nubs, but there's no technical reason why they'd HAVE to work this way. That leads to here: We mark the target as Ready during the UserInitializeTa
Topic:
App & System Services
SubTopic:
Drivers
Tags: