It's not impossible, you just haven't really defined the problem well. If you're saying, "how are the system calls made within the framework," you're inherently speaking with respect to some calling context. Could you use control flow analysis to approximate the calling contexts of programs as they use the system API and find out every possible set of API calls that would be made for a corresponding Java object method invocation? Sure you could, in theory, but would this be helpful? Maybe not, because it might not be how it is used.
My point was that there is, at some level, a proxy that implements the lowest level system calls, and those are accessed throughout the harmony build (constituting a fair amount of the runtime interaction you have with the system). Looking at this might be instructive, but you can always look at the implementation of other things, and find out how they use the lower level stuff. (OSNetworkProxy in this case..) kris On Sun, Jul 1, 2012 at 11:22 PM, M <[email protected]> wrote: > OK, Thanks all. It seems, this task is "impossible". > > On Jul 1, 7:34 pm, Kristopher Micinski <[email protected]> wrote: >> On Sun, Jul 1, 2012 at 10:27 PM, M <[email protected]> wrote: >> > so, how to correlate them? Any mapping files or mechanism inside the >> > device? >> >> Machiry's answer is right. The point is that in Java, the notion of a >> "system call" is heavily obscured. You could be holding onto a >> bufferedreader, writer, etc..., one of hundreds of objects >> implementing a high level interface. If you have an instance of this, >> how do you know what it really is: a socket, a file handle, etc? The >> answer to that question, is that you *can't* (easilly) look at an >> objects type and map it to a sytem call, you need a form of control >> flow analysis to do that, and even then, the mapping between the Java >> API and the low level POSIX interface is very hazy, because it's just >> this monstorously huge ugly API. >> >> kris > > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-kernel -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
