Re: Launching a Cocoa app from KEXT?
Re: Launching a Cocoa app from KEXT?
- Subject: Re: Launching a Cocoa app from KEXT?
- From: Dean Reece <email@hidden>
- Date: Mon, 18 Jul 2005 13:04:36 -0700
Allan,
The reason you will get push-back regarding designs that have the
kernel causing high-level events is that it is violates the layering
of the system. The basic design is that the kernel and it's
extensions are just a way for higher level software to get managed
access to system resources. The kernel (and it's extensions) should
not be directly causing high-level activity. It may be possible to
build things this way, but it does not fit the design of Mac OS X,
Darwin, or other Unix-like OSs.
Instead, you should turn this around and drive it from user space.
You can create a login item that runs in the user's session the
entire time they are logged in. This item (basically, a per-user
daemon) would open a socket, or talk to your kext however is needed,
and would facilitate launching any apps.
This design has several advantages:
1) It allows each user to decide if they want the service or not
(users can configure their login items)
2) The login item can monitor the user's session and take appropriate
actions at various events like FastUserSwitch, logout, sleep/wake,
etc. This really isn't possible from the kernel.
3) It maintains correct layering because the policy is being driven
from a user-space app (the login item), and the kernel is providing a
service to that app.
4) This is more-or-less how the digital camera example works, so you
know the model is supportable on Mac OS X
The only disadvantage of this approach is that it requires one
additional moving piece, but I think you'll find your job much easier
if you follow this model because all the APIs on the system are
geared for this type of activity. Trying to do it all from the
kernel will be an uphill battle.
Cheers,
- Dean
On Jul 18, 2005, at 12:46, Allan Hoeltje wrote:
Justin,
I guess I don't understand your aversion to having a KEXT do this.
For
example, when I plug a digital camera into the usb port the Mac OS
will
automatically launch iPhoto. Granted, maybe that particular event
does not
involve a KEXT but you get the idea? In a similar way, when my
KEXT detects
a particular situation (by way of examining IP packets flowing in
or out) I
want the KEXT to launch an application to let the user deal with the
situation.
The case I have in mind (I do not wish to reveal too much on-list
but if you
email me off-list I can say more) is that the user will not be
logged in
remotely and the IP packets that trigger the application will
always be
associated with an activity caused by that user. And the user will
be glad
to see the app come up. :-)
-Allan
"Justin C. Walker" <email@hidden> wrote on 7/18/05 12:04 PM:
On Jul 18, 2005, at 11:34 , Allan Hoeltje wrote:
Is it possible for a KEXT to launch a Cocoa application? What I
want is for
my KEXT to determine which user is logged-in and then open the app
in that
user's space as if the user double clicked the app.
That's mixing metaphors in a really bad way. You (the Editorial You)
don't want an extension to have any clue about identities of users,
or even about users. The only reason your extension should deal with
UIDs is for security issues.
Kernel operations should be performed to facilitate some user-level
activity, and then only if there is no other way. Think of the
kernel as a programming interface to the hardware, not as an
environment in which to build fancy applications.
One thing to consider is how you would tell that the user has logged
in in such a way that he can stand having a Cocoa app launched. He
might be remote, or he might be running X windows only.
There's got to be a better way to get what you want.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
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