site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com So if I were solving your specific problem, I would: -- Terry On Jan 27, 2006, at 2:54 PM, Peter Lovell wrote: Hi Terry, (your friends at SPARTA say "Hi" ) Do you happen to know if the following would work ... 1. CFM app under Rosetta does fork/exec of intel helper 2. helper loads kext (it's setuid already) 3. helper opens control socket to kext 4. helper passes descriptor back to CFM app 5. CFM app uses descriptor for control ioctls Thanks.....Peter On Jan 27, 2006, at 4:42 PM, Terry Lambert wrote: 2) File a bug and attach the program as source code. -- Terry Regards.....Peter On Jan 27, 2006, at 10:01 AM, AgentM wrote: On Jan 26, 2006, at 9: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; /* 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/agentm%40themactionfact... |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- AgentM agentm@themactionfaction.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/tlambert%40apple.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 answer is that #5 won't work, and you will need to proxy through the helper for this call. I'd still file the bug and contact DTS to try and get it in a software update; we're pretty darn responsive to that sort of thing, as long as it comes through the proper escalation channels instead of just mailing list postings grabbing a passing engineers attention. 8-). #5 won't work because the issue isn't the open descriptor instance, it's that the open descriptor from the PPC application can't make that specific ioctl() through Rosetta because Rosetta doesn't know how to convert between PPC and Intel byte order for the user argument that particular ioctl() (an address of a ctl_info structure). This is also true for user defined ioctl()'s as well (obviously), and it's true even for ioctl()'s that don't require byte-swapping, if they aren't on the "is transformed/will work" list known to Rosetta. This was basically a trade-off on the basis of the expectation that anything that talked to a KEXT would be in the same byte order as the KEXT itself (native byte order for the platform), and that many of these calls are root-only, and so have less protection in the kernel from bad data being passed from user space. So a blanket deny, with exceptions, was considered a better architecture to ensure system stability than a blanket allow would have been. So what you will need to do generically is to marshall the data over to the helper application, byte-swap the structure contents, make the call, byte-swap the result (if it's an input/output structure), and marshall the data back to the PPC application. In the particular case of the control message, you are retrieving information in a read/write parameter structure, and the information going down is not byte-swapped, because it's a string; the information coming back up *IS* byte-swapped, because it's a simple integer that the PPC code expects to see in PPC byte order. This means you have less work to do, since you can skip the byte order stuff on the way down for this one. (1) Start up a helper app I know how to communicate with (2) Open up the control socket in the PPC application (3) Pass the socket from the PPC app to the Intel app using a UNIX domain socket (4) Marshall the structure contents from the PPC app to the Intel app [given that it's a 32 bit integer and a character array, the packing should be the same on both ends] (5) Since you are passing in the string and getting back the integer, just make the call in the helper (6) Byte swap the integer portion of the structure to convert it from Intel to PPC byte order [PPC byte order is network byte order, so htonl() will work for this] (7) Close the fd in the Intel application [don't do this if you think you will need to do more work on it] (8) Marshall the structure contents, which are now in PPC byte order from the Intel app to the PPC app I'd also: (A) Have a way to indicate to the helper the byte order of the thing it's helping (B) Use the helper unconditionally, so the code paths are the same on both PPC and under Rosetta If you do this, then you can use a much simplified code path to have the helper always make the calls on behalf of the main application. It's actually my understanding that once the call is made with the control connection to get the association, that you will be able to deal with the byte order issues for the control messages you use by yourself; if not in the main application, then the KEXT can tell if the caller is Rosetta or not (there's a KPI for this in the BSD kernel exports). This is a great suggestion. I mentioned to Josh (email crossed this one) that there's already a helper app which would be easy to convert to native/universal, unlike the main application which will take quite some time. This helper loads the kext and passes the descriptor back to the main app. If the main app (CFM at present) can use the descriptor in the Rosetta environment, that would be great. If not, I'd keep the helper active and use it to proxy the data to my kext. In my case, I have full control over both ends and I don't have to worry about version incompatibility (the application makes sure that the kext is a matching version). Of course, flipping is my task and I realize that I have to deal with all the endian issues - no surprise there. If it won't, then I can filter/proxy through the helper (not all that much change) He's talking about using a helper program that is native Intel to make the call on your behalf (or potentially a number of calls, if you have other calls with the same problem). I've personally talked to one of the Rosetta developers about this issue, and they say that you need to: 1) Create a small program that demonstrates the issue(s) you need resolved. 3) Contact DTS in order to emphasize the importance of this issue to you, to ensure that it's considered as a candidate for a software update. In the mean time, using descriptor passing and IPC to communicate with an Intel native helper application would allow you to work around the problem; obviously, you would need to deal with the byte swap issues in the IPC mechanism you choose so that you get the right data back and forth. Assuming that you are going to use the results of this ioctl() to communicate between a userspace application and the KEXT, you could also consider using an alternate communications mechanism - e.g. a pseudo device entry in /dev, a Mach IPC, a string sysctl (string sysctls are not intercepted, being byte sysquences, since byte sequences don't have byte order issues), etc.. On Jan 27, 2006, at 12:28 PM, Peter Lovell wrote: Absolutely. I have complete control over the application (I guess, other than the speed with which I can convert it to fully native :) I can pre-change in application space, or post-change in my kext - doesn't make much difference AFAICT. Obviously I have to convert somewhere, as the data block is opaque (known to my app and kext, but not to kernel or Rosetta). So I know that's a task I have to do, but I just need a connection. Could you put an intermediate process into the user-space pipe chain which would dynamically change the byte-order of your messages? Obviously, you would only want it to run where the PPC app is on Intel. 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. /* open socket to NKE*/ if( (sock = socket(PF_SYSTEM, SOCK_STREAM, SYSPROTO_CONTROL)) == -1) RETERR(kPGPError_ResourceUnavailable); 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 This email sent to agentm@themactionfaction.com This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com