You shouldn't call registerService until you are ready to service requests from others. Shortly after the registerService call drivers could match against your driver. Mac OS X is multi-threaded so this could happen concurrently while you are still in your start method. So don't register until you are ready. /*! @function registerService @abstract Start the registration process for a newly discovered IOService. @discussion This function allows an IOService subclass to be published and made available to possible clients, by starting the registration process and delivering notifications to registered clients. The object should be completely setup and ready to field requests from clients before registerService is called. @param options The default zero options mask is recommended & should be used in most cases. The registration process is usually asynchronous, with possible driver probing & notification occurring some time later. kIOServiceSynchronous may be passed to carry out the matching and notification process for currently registered clients before returning to the caller. */ -Shawn On Thursday, May 30, 2002, at 11:38 AM, Francis bouchard wrote: On 30/05/02 14:33, "Godfrey van der Linden" <gvdl@apple.com> wrote: Then call at starttime have com_matrox_driver_Effects::start(provider) call registerService() just before returning. Does the fact that calling this function not at the end of the start could change things ? It is actually done in a base class (derived from IOService) for our dirvers. So: com_matrox_driver_Effects::start(provider) { super::start(); // registerService() is done here // more stuff } Francis _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.