• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Kext Load on demand and daemon communication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kext Load on demand and daemon communication


  • Subject: Re: Kext Load on demand and daemon communication
  • From: Eric Long <email@hidden>
  • Date: Wed, 17 Oct 2007 11:44:25 -0700
  • Thread-topic: Kext Load on demand and daemon communication

> In the meantime, there are some less-than-ideal workarounds:
>
> o As Shaun mentioned, there's KUNC.
>
> o Another option is for your launchd property list to specify some
> on-demand criteria that your KEXT satisfies.  For example, your
> launchd property list could register a UNIX domain socket with a well
> known path.  When your KEXT comes up, it connects to that socket,
> thereby triggering the launch of your daemon.

That's good information for the list.

In my case, I have a daemon that is always up for other reasons.  It just
needs to know when my kext is loaded.

I looked at IOServiceAddMatchingNotification(). That seems pretty
straight-forward.  What I'm not clear on is what stage my driver will be in
when I get a notice in my callback.

What I want my daemon to do is to configure my kext, then listen for
messages from it that it must respond to.

I expect at the time my daemon is launched there may be driver instances
already published before my daemon came up.  The kext will be using default
behaviors at this point, because it can't read any settings from disk
itself.  The daemon will configure the kext to handle future events, then
start listening to the it for messages.  That's as much as I can do for
existing instances.

In the case of notices I receive in my callback...

So long as there is any published driver I want to listen for messages from
my kext.  I can track that by counting publications vs. terminations.

If I receive a first published notice for my driver at a time when there are
no other published services, my daemon need to configure the kext via is
user client and start listening for messages from it.

In this case, however, I don't want my driver's validateNewMedia() method to
execute before I have sent configuration info to the kext's user client and
I am listening for messages.

Is there a way I can count on doing this in terms of the order of
operations?  I mean, if I set this all up when I receive the publish notice
in the daemon, before exiting the callback, am I ok?  Is there something
else I should do?

I'm just trying to figure out how to make this work.


Thanks,


Eric


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Kext Load on demand and daemon communication
      • From: Michael Smith <email@hidden>
References: 
 >Re: Kext Load on demand and daemon communication (From: Eric Long <email@hidden>)

  • Prev by Date: Re: Launchd API documentation
  • Next by Date: Re: Kext Load on demand and daemon communication
  • Previous by thread: Re: Kext Load on demand and daemon communication
  • Next by thread: Re: Kext Load on demand and daemon communication
  • Index(es):
    • Date
    • Thread