On Tue, 30 Aug 2016 14:45:05 -0700 Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > I wonder: could more of it be dynamically allocated? I.e. statically > generate metadata with args and name and whatever but without any nr. > Then dynamically allocate the map from nr to metadata? Any ideas on how to do that? > > > > > > > Could we at least have an array of (arch, nr) instead of just an array > > > of nrs in the metadata? > > > > I guess I'm not following you on what would be used for "arch". > > Whatever syscall_get_arch() would return for the syscall. For x86, > for example, most syscalls have a compat nr and a non-compat nr. How > does tracing currently handle that? We currently disable tracing compat syscalls. What the current code does, is that the macro and linker magic creates a list of meta data structures, that have a name attached to them. Then on boot up, we scan the list of syscall numbers and then ask the arch for the system call they represent to get the actual function itself: addr = arch_syscall_addr(i); where 'i' is the system call nr. Then the find_syscall_meta(addr) will do a ksyms_lookup to convert the addr into the system call name, and then search the meta data for one that has that name attached to it. Yes it is ugly. But we don't currently have a method to automatically match the meta data with the system call numbers. The system call macros only have access to the names and the parameters, not the numbers that are associated with them. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
