Re: OSX 10.5.6 breaks our user-land driver
Re: OSX 10.5.6 breaks our user-land driver
- Subject: Re: OSX 10.5.6 breaks our user-land driver
- From: Jeff Moore <email@hidden>
- Date: Wed, 07 Jan 2009 14:27:46 -0800
Yes. We use bootstrap_look_up directly in our client processes to look
up the registration port of coreaudiod by name.
The only catch in your case is that your plug-in in coreaudiod is
going to want to call bootstrap_register() in order to set up the
mapping between your name and your port. Unfortunately,
bootstrap_register() is deprecated. In coreaudiod's case, we avoid
this problem by having launchd manage the name to port mapping.
You can't do that in your case since you don't control the launchd
plist for coreaudiod. One thing you could do though, is create a
separate launchd daemon whose sole job is to map names to ports. You
could think of it as a private bootstrapping service. Whenever one of
your plug-ins was instantiated, it could message this daemon to map a
name to a port in the process the plug-in is in. It could then also
message this daemon to look up a port by name.
You could also move your daemon that is living in the user session
that your plug-in in coreaudiod is looking for out into the global
session. The complication here is that I imagine that the reason you
do a per-user daemon is that you are using that as a way to scope any
per-user state. Moving the daemon out to the global session would
entail retooling your daemon so that it can manage connections from
multiple users. One way to do that would be to have a session based
approach where each user logged into the daemon and the daemon managed
the per-user state as it changed implicitly. Another way would be to
make sure that any necessary per-user data is always sent along with
each IPC message. I prefer to use the latter approach where possible
because it is, in essence, a state-less connection and so requires a
lot less support in the server.
On Jan 7, 2009, at 1:26 PM, Stéphane Letz wrote:
>That sort of operation was never supposed to work in the past. The
fact that it did work for you is something of a surprise to me.
>At any rate, the bootstrap context stuff is not something
coreaudiod manipulates. It's just a happy user. To my knowledge, we
didn't change anything about how coreaudiod interacts with >launchd
or the bootstrap contexts at all in 10.5.6. In fact, the fact that
it stopped working in 10.5.6 probably means some security loophole
got closed somewhere below coreaudiod.
>My understanding is that the official way for a process in a parent
bootstrap session to get a send right to a port in a process in a
child bootstrap session is to have the process in the child
>bootstrap session to bootstrap look-up a port in the process in the
parent session and then message that port the send right to use.
This is in fact how the both the HAL and the System Sound >Server
implement their communication with coreaudiod.
Thanks.
Are you directly using "bootstrap_look_up" kind of API to implement
that, or anything higher level?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden