From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758730AbcH3TyQ (ORCPT ); Tue, 30 Aug 2016 15:54:16 -0400 Received: from mail-ua0-f178.google.com ([209.85.217.178]:34694 "EHLO mail-ua0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755506AbcH3TyO (ORCPT ); Tue, 30 Aug 2016 15:54:14 -0400 MIME-Version: 1.0 In-Reply-To: <20160830152955.17633511@gandalf.local.home> References: <1472463007-6469-1-git-send-email-marcin.nowakowski@imgtec.com> <20160830152955.17633511@gandalf.local.home> From: Andy Lutomirski Date: Tue, 30 Aug 2016 12:53:53 -0700 Message-ID: Subject: Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall To: Steven Rostedt Cc: Marcin Nowakowski , Linux API , Ingo Molnar , open list , Linux MIPS Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 30, 2016 at 12:29 PM, Steven Rostedt wrote: > On Tue, 30 Aug 2016 11:52:39 -0700 > Andy Lutomirski wrote: > > >> Okay, I think I see what's going on. init_ftrace_syscalls() does: >> >> meta = find_syscall_meta(addr); >> >> Unless I'm missing some reason why this is a sensible thing to do, >> this seems overcomplicated and incorrect. There is exactly one caller >> of find_syscall_meta() and that caller knows the syscall number. Why >> doesn't it just look up the metadata by *number* instead of by syscall >> implementation address? There are plenty of architectures for which >> multiple logically different syscalls can share an implementation >> (e.g. pretty much everything that calls in_compat_syscall()). > > The problem is that the meta data is created at the syscalls > themselves. Look at all the macro magic in include/linux/syscalls.h, > and search for __syscall_metadata. The meta data is created via linker > magic, and the find_syscall_meta() is what finds a specific system call > and the meta data associated with it. Egads! OK, I see why this is a mess. I guess we should be creating the metadata from the syscall tables instead of from the syscall definitions, but I guess that's currently a nasty per-arch mess. Could we at least have an array of (arch, nr) instead of just an array of nrs in the metadata? --Andy