site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Allan, Cheers, - Dean Justin, -Allan "Justin C. Walker" <justin@mac.com> 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. This email sent to dean.reece@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. On Jul 18, 2005, at 12:46, Allan Hoeltje wrote: 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. :-) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/dean.reece% 40apple.com This email sent to site_archiver@lists.apple.com