Re: cross Arch communication to NKE?
Re: cross Arch communication to NKE?
- Subject: Re: cross Arch communication to NKE?
- From: Peter Lovell <email@hidden>
- Date: Fri, 27 Jan 2006 17:54:02 -0500
Hi Terry,
(your friends at SPARTA say "Hi" )
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.
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
If it won't, then I can filter/proxy through the helper (not all that
much change)
Thanks.....Peter
On Jan 27, 2006, at 4:42 PM, Terry Lambert wrote:
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.
2) File a bug and attach the program as source code.
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..
-- Terry
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.
Regards.....Peter
On Jan 27, 2006, at 10:01 AM, AgentM wrote:
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.
On Jan 26, 2006, at 9:42 PM, Peter Lovell wrote:
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?
Regards.....Peter
On Jan 26, 2006, at 6:52 PM, Josh Graessley wrote:
No.
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.
-josh
On Jan 26, 2006, at 3:26 PM, Vinnie Moscaritolo wrote:
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.
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);
and when making the ioctl, my app dies with SIGILL
"Unhandled transform (1) for ioctl group = 78 (N), number = 3,
length = 100"
what does this mean?
--
Vinnie Moscaritolo
ITCB-IMSH
PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042
-------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.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:
40mac.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:
40themactionfaction.com
This email sent to email@hidden
|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
AgentM
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:
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