On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > 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? This might be as simple as dropping the syscall_nr field from syscall_metadata. I admit I'm not familiar with this code at all, but I'm not really sure why that field is needed. init_ftrace_syscalls is already dynamically allocating an array that maps nr to metadata, and I don't see what in the code actually needs that mapping to be one-to-one or needs the reverse mapping. > >> >> > > >> > > 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. > Yeah, I think I get it now. But I think my suggestion of removing syscall_nr entirely might actually work. You'd have to initialize more than one syscalls_metadata array, but they could share the underlying metadata objects. --Andy -- Andy Lutomirski AMA Capital Management, LLC
