August 2009 - Darwin-dev - lists.apple.com

assembly jmp to hard-coded address with gcc
by Aron-Zvi 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=fJaMtTchN4Ha2MuB07GGKhMgKF1v7v3xk1u4sXhUW/Q=; b=aOZKR/Z9m+9DZsYlrXsXHFSE5OeIapTT8hQ4ImzbDe+ROUl+giCimTfwDNjtTB9BDI KBjnjmpMIHWH1+7H3yWDzrFnZPze03vvYggARsmgdMhq2AuHFrculZ8OlEEVDM7ZU6ki falF5fku5uVfkx781GBor1jwW3DU36i+zeyNo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=TRdD51d6kUq7EV0dXtk7Km1uF2nvnEDkWK/17SITRvB0doW7OTPc0k0A0Xia0ptXB8 CzLNzWWg9dSFJL0cM8crjy9TZPclgWvqyq8BRoTq5tiYLjMhk1p4Zb8oknnUZAnnhhPy 4Grl0jLv+gffZ1sK5dA1A01cVkqXdh1usLotk= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: dns_lookup returns NULL?
by Josh Graessley 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com That will dump the state to the system log. Potentially useful is: scutil --dns -josh On Aug 11, 2009, at 2:46 PM, Paul Kwan wrote: PSK On 8/11/09 2:37 PM, "Josh Graessley" <jgraessley(a)apple.com> wrote: I believe the most common cause of this failure is a configd crash (usually in one of the plug-ins). If configd crashes, other parts of the system are unaware that they will no longer receive notification of network changes. mDNSResponder loses DNS settings. -josh On Aug 11, 2009, at 2:32 PM, Marc Majka wrote: On 10.6, DNS queries are sent to mDNSResponder rather than to DirectoryService as they were on 10.5. If you can reproduce the problem, you may be able to collect some useful debugging output from mDNSResponder. See the mDNSResponder man page for info on getting debug log info. If you can get some data, please file a bug report. You are correct: dig, nslookup, and host all use bare-bones network routines from BIND. The follow a very different code path than mDNSResponder. -- Marc On 11 Aug, 2009, at 14:17, Mike Patnode wrote: I'll buy that. Any idea why on 10.6 it would suddenly start returning NULL for all lookups and continue to do so until a reboot? Tried restarting DS as well to no avail but a reboot seems to solve the problem once the system gets in that state. Where should I start looking for debug info? Note that dig and nslookup work fine, but I suspect they don't use this API. mp Date: Mon, 10 Aug 2009 15:25:55 -0700 From: Marc Majka <majka(a)apple.com> Subject: Re: dns_lookup returns NULL? To: appledev <appledev(a)centrify.com> Cc: darwin-dev(a)lists.apple.com Message-ID: <EB755AEA-2B4B-4D95-B453-4E538C1E6EC2(a)apple.com> Content-Type: text/plain; charset="us-ascii" -- Marc Majka On 10 Aug, 2009, at 14:37, Mike Patnode wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jgraessley%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… There are a few more steps you can take to try and narrow down the cause of the problem. dns-sd talks directly to mDNSResponder so you can check to see if that is working: dns-sd -G v4 www.google.com If that's failing, there may be clues in mDNSResponders state. You can dump that state using: sudo killall -INFO mDNSResponder That will dump the global DNS settings. mDNSResponder should be using those DNS settings. In our test environment where it happens, there are no configd core dumps in /cores folder or crash reports in /Library/Logs/CrashReporter and /Library/Logs/DiagnosticReports folders. The "status" field of the dns_reply_t structure is currently unused (it's always zero). There's really not a lot of useful error information that could be returned by this level of API. dns_lookup () may do multiple queries to multiple DNS clients (see the resolver (5) man page). If none of the resolvers returned useful data for the query, dns_lookup() returns NULL. A failure like NXDomain from a particular nameserver really doesn't mean much if dns_lookup() is searching multiple sources. The situation is similar to an API like, say, getpwnam(). The DirectoryService daemon might search many different information sources to answer a getpwnam() query. If it finds data, it returns it. It really doesn't mean a lot if, as part of it's search, it got an error from an LDAP or NIS server, or if it checked /etc/passwd and failed to find a particular user. A reply is really a composite of all of the sub-searchs performed to answer a query. A NULL reply means they all "failed" in some way, but the API abstracts away the return codes for the various sub-systems. Is there anyway to get error information when dns_lookup() returns NULL? It looks like the error code is supposed to be returned in the dns_reply_t structure. What does it mean when the return value is NULL? thx mp _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka %40apple.com This email sent to majka(a)apple.com This email sent to majka(a)apple.com This email sent to jgraessley(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: dns_lookup returns NULL?
by Josh Graessley 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -josh On Aug 11, 2009, at 2:32 PM, Marc Majka wrote: -- Marc On 11 Aug, 2009, at 14:17, Mike Patnode wrote: mp Date: Mon, 10 Aug 2009 15:25:55 -0700 From: Marc Majka <majka(a)apple.com> Subject: Re: dns_lookup returns NULL? To: appledev <appledev(a)centrify.com> Cc: darwin-dev(a)lists.apple.com Message-ID: <EB755AEA-2B4B-4D95-B453-4E538C1E6EC2(a)apple.com> Content-Type: text/plain; charset="us-ascii" -- Marc Majka On 10 Aug, 2009, at 14:37, Mike Patnode wrote: Is there anyway to get error information when dns_lookup() returns NULL? It looks like the error code is supposed to be returned in the dns_reply_t structure. What does it mean when the return value is NULL? thx mp _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jgraessley%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I believe the most common cause of this failure is a configd crash (usually in one of the plug-ins). If configd crashes, other parts of the system are unaware that they will no longer receive notification of network changes. mDNSResponder loses DNS settings. On 10.6, DNS queries are sent to mDNSResponder rather than to DirectoryService as they were on 10.5. If you can reproduce the problem, you may be able to collect some useful debugging output from mDNSResponder. See the mDNSResponder man page for info on getting debug log info. If you can get some data, please file a bug report. You are correct: dig, nslookup, and host all use bare-bones network routines from BIND. The follow a very different code path than mDNSResponder. I'll buy that. Any idea why on 10.6 it would suddenly start returning NULL for all lookups and continue to do so until a reboot? Tried restarting DS as well to no avail but a reboot seems to solve the problem once the system gets in that state. Where should I start looking for debug info? Note that dig and nslookup work fine, but I suspect they don't use this API. The "status" field of the dns_reply_t structure is currently unused (it's always zero). There's really not a lot of useful error information that could be returned by this level of API. dns_lookup () may do multiple queries to multiple DNS clients (see the resolver (5) man page). If none of the resolvers returned useful data for the query, dns_lookup() returns NULL. A failure like NXDomain from a particular nameserver really doesn't mean much if dns_lookup() is searching multiple sources. The situation is similar to an API like, say, getpwnam(). The DirectoryService daemon might search many different information sources to answer a getpwnam() query. If it finds data, it returns it. It really doesn't mean a lot if, as part of it's search, it got an error from an LDAP or NIS server, or if it checked /etc/passwd and failed to find a particular user. A reply is really a composite of all of the sub-searchs performed to answer a query. A NULL reply means they all "failed" in some way, but the API abstracts away the return codes for the various sub-systems. This email sent to majka(a)apple.com This email sent to majka(a)apple.com This email sent to jgraessley(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: dns_lookup returns NULL?
by Marc Majka 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Marc On 11 Aug, 2009, at 14:17, Mike Patnode wrote: mp Date: Mon, 10 Aug 2009 15:25:55 -0700 From: Marc Majka <majka(a)apple.com> Subject: Re: dns_lookup returns NULL? To: appledev <appledev(a)centrify.com> Cc: darwin-dev(a)lists.apple.com Message-ID: <EB755AEA-2B4B-4D95-B453-4E538C1E6EC2(a)apple.com> Content-Type: text/plain; charset="us-ascii" -- Marc Majka On 10 Aug, 2009, at 14:37, Mike Patnode wrote: Is there anyway to get error information when dns_lookup() returns NULL? It looks like the error code is supposed to be returned in the dns_reply_t structure. What does it mean when the return value is NULL? thx mp _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On 10.6, DNS queries are sent to mDNSResponder rather than to DirectoryService as they were on 10.5. If you can reproduce the problem, you may be able to collect some useful debugging output from mDNSResponder. See the mDNSResponder man page for info on getting debug log info. If you can get some data, please file a bug report. You are correct: dig, nslookup, and host all use bare-bones network routines from BIND. The follow a very different code path than mDNSResponder. I'll buy that. Any idea why on 10.6 it would suddenly start returning NULL for all lookups and continue to do so until a reboot? Tried restarting DS as well to no avail but a reboot seems to solve the problem once the system gets in that state. Where should I start looking for debug info? Note that dig and nslookup work fine, but I suspect they don't use this API. The "status" field of the dns_reply_t structure is currently unused (it's always zero). There's really not a lot of useful error information that could be returned by this level of API. dns_lookup() may do multiple queries to multiple DNS clients (see the resolver(5) man page). If none of the resolvers returned useful data for the query, dns_lookup() returns NULL. A failure like NXDomain from a particular nameserver really doesn't mean much if dns_lookup() is searching multiple sources. The situation is similar to an API like, say, getpwnam(). The DirectoryService daemon might search many different information sources to answer a getpwnam() query. If it finds data, it returns it. It really doesn't mean a lot if, as part of it's search, it got an error from an LDAP or NIS server, or if it checked /etc/passwd and failed to find a particular user. A reply is really a composite of all of the sub-searchs performed to answer a query. A NULL reply means they all "failed" in some way, but the API abstracts away the return codes for the various sub-systems. This email sent to majka(a)apple.com This email sent to majka(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: dns_lookup returns NULL?
by Mike Patnode 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcoayRXDv8kXFlABT/a/fuDuHqsvUw== Thread-topic: Re: dns_lookup returns NULL? I'll buy that. Any idea why on 10.6 it would suddenly start returning NULL for all lookups and continue to do so until a reboot? Tried restarting DS as well to no avail but a reboot seems to solve the problem once the system gets in that state. Where should I start looking for debug info? Note that dig and nslookup work fine, but I suspect they don't use this API. mp Date: Mon, 10 Aug 2009 15:25:55 -0700 From: Marc Majka <majka(a)apple.com> Subject: Re: dns_lookup returns NULL? To: appledev <appledev(a)centrify.com> Cc: darwin-dev(a)lists.apple.com Message-ID: <EB755AEA-2B4B-4D95-B453-4E538C1E6EC2(a)apple.com> Content-Type: text/plain; charset="us-ascii" The "status" field of the dns_reply_t structure is currently unused (it's always zero). There's really not a lot of useful error information that could be returned by this level of API. dns_lookup() may do multiple queries to multiple DNS clients (see the resolver(5) man page). If none of the resolvers returned useful data for the query, dns_lookup() returns NULL. A failure like NXDomain from a particular nameserver really doesn't mean much if dns_lookup() is searching multiple sources. The situation is similar to an API like, say, getpwnam(). The DirectoryService daemon might search many different information sources to answer a getpwnam() query. If it finds data, it returns it. It really doesn't mean a lot if, as part of it's search, it got an error from an LDAP or NIS server, or if it checked /etc/passwd and failed to find a particular user. A reply is really a composite of all of the sub-searchs performed to answer a query. A NULL reply means they all "failed" in some way, but the API abstracts away the return codes for the various sub-systems. -- Marc Majka On 10 Aug, 2009, at 14:37, Mike Patnode wrote: > Is there anyway to get error information when dns_lookup() returns > NULL? It looks like the error code is supposed to be returned in > the dns_reply_t structure. What does it mean when the return value > is NULL? > > thx > mp > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/majka%40apple.com > > This email sent to majka(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Loading Kernel Extension
by Terry Lambert 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com <http://en.wikipedia.org/wiki/Unix_philosophy> kextload -b com.mycompany.driver.TabletDriver <http://developer.apple.com/qa/qa2001/qa1319.html> -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Aug 11, 2009, at 12:17 PM, Eli Bach wrote: On Aug 11, 2009, at 11:40 AM, Tim Murison wrote: What is the reason why you don't want to use kextload? I generally prefer not invoking a utility from within my own program unless I have to. It strikes me as an ugly way of performing a task. If there is no other way then I'll invoke kextload, I was just hoping for an overlooked API. As far as I know, invoking kextload is the way to go. And of course, you'll need to invoke it with root-level privileges. I also recommend Mike Gancarz excellent book "The UNIX Philosopy". Here a the related Wikipedia article: In general, it recommends building larger tools out of combinations of smaller tools which do one thing, and do it well. While the underlying API used by kextload may change from release to release, or even as a result of a Software Update, the minimum set of options usually doesn't change as often; for example, the following command has been documented since 2002: That's true even though the underlying infrastructure has changed significantly over time. That said, you should most likely be using matching rules for you KEXT, if at all possible, and let it be loaded automatically by kextd, as needed. See also: For non-IOKit based KEXTs, your only options are likely to load your KEXT at boot time, or to specifically invoke kextload as a subprocess. See also the manual page for the popen(3) library routine. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Loading Kernel Extension
by Eli Bach 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=uCOOrcK8q7C8kKYudvQKCSOshucURIW1j5YdH4mJph8=; b=Q8Yd1pm0L9qvWfAUR/Kx46XXk+rFc+hLwjczj8InKBYI5SqfXsbbT3ZaZjTT+Oo2MH s3bNKcLoreiPjFiDIEBaJmWcuD8AaeqOUbUUntcj3XGvbAZYv1PHZbEL8RtF5SsFHZVZ TrPgJLbchD0oIF27HQOqBhfypXgGICtyyBolM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=wEw0G1IX0O4traYFm6iYxtEv14rg4O/p/b5b3+aquVw1rsgV69KUaxdLJg4FjgXnOt mh4Vm3sn0Z0Yt33XcRFWWumCJk2S60byC/Ybph5Fde/NM6Pr/HS/sgb3oki4IRUrhQGN oq9+RwMeCYaFBtSCpmYViEPWGU0x/nM2VO/xc= On Aug 11, 2009, at 11:40 AM, Tim Murison wrote: Eli _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… What is the reason why you don't want to use kextload? I generally prefer not invoking a utility from within my own program unless I have to. It strikes me as an ugly way of performing a task. If there is no other way then I'll invoke kextload, I was just hoping for an overlooked API. As far as I know, invoking kextload is the way to go. And of course, you'll need to invoke it with root-level privileges. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Loading Kernel Extension
by Tim Murison 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcoaszJenBj4DFIkv0SLvX6FoeOYcA== Thread-topic: Loading Kernel Extension User-agent: Microsoft-Entourage/12.20.0.090605 > What is the reason why you don't want to use kextload? I generally prefer not invoking a utility from within my own program unless I have to. It strikes me as an ugly way of performing a task. If there is no other way then I'll invoke kextload, I was just hoping for an overlooked API. *********************************************************************** This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Loading Kernel Extension
by Eli Bach 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=wtedlryr95uMJTvvi3tHJkggK252rUvLKT68gfGmmJQ=; b=DauaZ5stnhuCC4lvDJTbshqWHTHKFKMfe/UH02BVCXKTXuvE4N8SiO5bpJZa/vC8Tv uc5aT4Ud5R4UuxstMHfp9q1pb6tcEN6ouJ2729Uim4J4065MA0fpqTFDm1lSttQfEYWh DaEXMfMQ6gcoFB6C9F34/675S+N22GPSHVLow= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=pK2AIWTFFQfpHUP93tjdOKtculJx8MqheSXxLT4p/VmCmPj1Mfp9kTcA9cJLQoVofG AbPmNVt7jdVNCkBpzV9g8OWhmkGOV2Wy4FMCz2TiY6hEfwa0g+74x5dmEaQK4Ma5cbM2 O+vCBkUdWr9XjV9F4xFwCunutYJ5d9NTuH478= On Aug 11, 2009, at 11:28 AM, Tim Murison wrote: Hi, Is there a recommended approach to DIY loading/unloading of kernel extensions in Leopard? What is the reason why you don't want to use kextload? Eli _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I would like to load a kernel extension from my code preferably without invoking kextload. The nice APIs to do this seem to be private in Leopard with the exception of the kld.h functions that I'm not sure I understand. -Tim Um, this is asking "How do I do X, but without using the clearly defined, supported method of doing X." There are a number of operations where the supported way for code to do X, is to just launch another process to do the work, then look at the output of that process to figure out if it succeeded and/or what the results of the operation are. This email sent to site_archiver(a)lists.apple.com

1 0

Loading Kernel Extension
by Tim Murison 11 Aug '09

11 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcoasYeZ6L4T9dCAuU67Muh7jLaMSg== Thread-topic: Loading Kernel Extension User-agent: Microsoft-Entourage/12.20.0.090605 Hi, I would like to load a kernel extension from my code preferably without invoking kextload. The nice APIs to do this seem to be private in Leopard with the exception of the kld.h functions that I'm not sure I understand. Is there a recommended approach to DIY loading/unloading of kernel extensions in Leopard? -Tim *********************************************************************** This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0