My objective is to identify the USB device and need to launch the USB authentication application which will open the USB drive/partition. So I am registering the USB arrival and removal in the init() See below functions.
- ( id )init
{
[super init];
// Register ourself for callbacks when the devices we want
// to know about come online/leave
deviceNotifyPort
= MACH_PORT_NULL;
deviceAppearedIterator
= 0;
deviceDisappearedIterator
= 0;
[self registerDeviceCallbackHandler ];
return self;
}
- ( void ) registerDeviceCallbackHandler
{
mach_port_t masterPort;
CFRunLoopRef runLoop;
CFDictionaryRef classToMatch;
CFRunLoopSourceRef
runLoopSource;
// Get a handle to the master port for IOKit
if ( KERN_SUCCESS != IOMasterPort(
MACH_PORT_NULL, &masterPort) )
{
return;
}
// Create the port on which we will receive notifications. We'll wrap it in a runLoopSource
// which we then feed into the runLoop for async event notifications.
deviceNotifyPort = IONotificationPortCreate
( masterPort );
if ( deviceNotifyPort
== NULL )
{
mach_port_deallocate ( mach_task_self ( ), masterPort );
return;
}
// Get a runLoopSource for our mach port.
runLoopSource = IONotificationPortGetRunLoopSource
( deviceNotifyPort );
classToMatch = IOServiceMatching(
kOnSpecCDDriverIOKitClassName);
if ( classToMatch == NULL )
{
return;
}
// Retain a reference since we arm both the appearance and disappearance notifications
// and the call to IOServiceAddMatchingNotification() consumes a reference each time.
classToMatch = ( CFMutableDictionaryRef ) CFRetain ( classToMatch );
IOServiceAddMatchingNotification (
deviceNotifyPort,
kIOFirstMatchNotification
,
classToMatch,
AppearedNotificationHandler,
( void * ) self
,
&deviceAppearedIterator
);
// Since we got back an iterator already from this routine, we call the handler to immediately
// dispatch any devices there already
AppearedNotificationHandler( (void
*) self, deviceAppearedIterator);
IOServiceAddMatchingNotification (
deviceNotifyPort,
kIOTerminatedNotification,
classToMatch,
DisappearedNotificationHandler,
( void * )
self,
&deviceDisappearedIterator );
// Since we got back an iterator already from this routine, we call the handler to immediately
// dispatch any devices removed already
DisappearedNotificationHandler( (void
*) self, deviceDisappearedIterator );
// Get our runLoop
runLoop = [ [ NSRunLoop currentRunLoop ] getCFRunLoop ];
// Add our runLoopSource to our runLoop
CFRunLoopAddSource ( runLoop, runLoopSource, kCFRunLoopDefaultMode
);
// Deallocate the masterPort we allocated
mach_port_deallocate ( mach_task_self ( ), masterPort );
return;
}
The above code works fine in the Mac Tiger and it gives the problem in Mac Leopard. Please advise me to solve this issue.
Regards,
Elango C
Are you fork()'ing that process and attempting to use CF-level
functionality
in the fork child ? This is not supported, and in 10.5 some checks
have been added
to error out if CF is used in a fork child.
For daemons/agents started via launchd, forking (or using daemon())
should be unnecessary.
If there is a good reason for creating a new process, you'll have to
exec or posix_spawn()
the executable.
Eric
--
Elango C
CompuApps, Inc.
Chennai, India.
website:
http://celango.blogspot.com"Obstacles are those frightful things you see
when you take your eyes off your goal."