site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com I would recommend filing a bug report and contacting DTS. -josh On Jan 26, 2006, at 7:42 PM, Peter Lovell wrote: Regards.....Peter On Jan 26, 2006, at 6:52 PM, Josh Graessley wrote: No. -josh On Jan 26, 2006, at 3:26 PM, Vinnie Moscaritolo wrote: Specifically I do the following: #define MY_NKE_KEXT_NAME "com.me.kext.mynke" struct ctl_info ctl_info; int sock; /* open socket to NKE*/ if( (sock = socket(PF_SYSTEM, SOCK_STREAM, SYSPROTO_CONTROL)) == -1) RETERR(kPGPError_ResourceUnavailable); /* get NKE ID */ bzero(&ctl_info, sizeof(struct ctl_info)); strcpy(ctl_info.ctl_name, MY_NKE_KEXT_NAME); if (ioctl(sock, CTLIOCGINFO, &ctl_info) == -1) RETERR(kPGPError_FeatureNotAvailable); what does this mean? -- _______________________________________________ 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/vpndev%40mac.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... This email sent to site_archiver@lists.apple.com I would guess that this is unlikely this unlikely to be fixed. Such a change would have to go in a software update. The content of software updates is strictly controlled. If the decision was made to incorporate such a change, it may take many months for it to get in to a software update. That makes the fix of dubious value. If it takes longer for the fix to get out than for the developer to transition their client to a universal binary, the fix was wasted effort. This is a really big deal. I have an app which will move only slowly to native, rather than "real soon now". Converting the kext was already on my list, but not the whole app! Is there a way we can have the ioctl code handled, and let us deal with the parameters?? Even a new ioctl, so that there aren't compatibility issues with existing apps? One of the challenges here is that on Intel, your kext is running little endian. Your user space process is running in big endian in Rosetta. For many common ioctls, there is code, I believe in Rosetta, to translate the ioctl code itself as well as parameters from big endian to little endian. The CTLIOGINFO ioctl for the SYSPROTO_CONTROL protocol is not supported. Were it supported, the kext would have to determine the byte order of the client since the kernel can not know the format of data passed between the user space process and the kext. In addition to making your kext a universal binary, you also need to make the client that talks to your kext a universal binary. Is communication from allowed from an app running in Rosetta to an intel NKE? I have a fat NKE installed. I seem to be able to communicate to it to some extent when my app is running under intel, but when my app runs under PPC I get an exeception. and when making the ioctl, my app dies with SIGILL "Unhandled transform (1) for ioctl group = 78 (N), number = 3, length = 100" Vinnie Moscaritolo ITCB- IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 ------------------------------------------------------- _______________________________________________ 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/jgraessley% 40apple.com This email sent to jgraessley@apple.com This email sent to vpndev@mac.com smime.p7s