From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9426 invoked by alias); 14 Feb 2010 10:44:32 -0000 Received: (qmail 9405 invoked by uid 48); 14 Feb 2010 10:44:22 -0000 Date: Sun, 14 Feb 2010 10:44:00 -0000 Message-ID: <20100214104422.9404.qmail@sourceware.org> From: "mjw at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20100209125924.11263.mjw@redhat.com> References: <20100209125924.11263.mjw@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug tapsets/11263] exposing foo32 syscalls X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00386.txt.bz2 ------- Additional Comments From mjw at redhat dot com 2010-02-14 10:44 ------- Another wrinkle since 2.6.33: commit f8b7256096a20436f6d0926747e3ac3d64c81d24 Author: Al Viro Date: Mon Nov 30 17:37:04 2009 -0500 Unify sys_mmap* New helper - sys_mmap_pgoff(); switch syscalls to using it. Acked-by: David S. Miller Signed-off-by: Al Viro This means everything is gated through sys_mmap_pgoff now on both x86_64 and i386. But that also makes it hard to distinguish syscall.mmap (what we call sys_mmap on x86_64) and syscall.mmap2 (what we call sys32_mmap on i386). I don't immediately see how we can keep providing syscall.mmap2 without also triggering syscall.mmap for the user. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11263 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.