From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14024 invoked by alias); 5 Feb 2009 21:02:03 -0000 Received: (qmail 13949 invoked by uid 22791); 5 Feb 2009 21:02:02 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Feb 2009 21:01:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n15L1rO5004761 for ; Thu, 5 Feb 2009 16:01:53 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n15L1rWp029186 for ; Thu, 5 Feb 2009 16:01:53 -0500 Received: from [10.11.231.126] (dhcp231-126.rdu.redhat.com [10.11.231.126]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n15L1p1t002423; Thu, 5 Feb 2009 16:01:51 -0500 Message-ID: <498B53BE.8020900@redhat.com> Date: Thu, 05 Feb 2009 21:07:00 -0000 From: William Cohen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: SystemTAP Subject: Re: Return values for vm.pagefault.return changed with newer kernels References: <4989F643.8090204@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2009-q1/txt/msg00369.txt.bz2 Frank Ch. Eigler wrote: > William Cohen writes: > >> [...] >> Seems like the saner way to take care of this is to move the this information >> into the tapsets/memory.stp [...] >> >> function vm_fault_minor(long:fault_no) >> function vm_fault_major(long:fault_no) >> function vm_fault_oom(long:fault_no) >> function vm_fault_sigbus(long:fault_no) >> function vm_fault_error(long:fault_no) > > I guess we need to speculate about future uses and possible future > changes of this stuff. It would make about as much sense to have > something smaller api-wise: > > a single test function > function vm_fault_class_p(fault_number:long, class:string) > and a variable that lists available classes > global vm_fault_classes:string [] > > ... or else to have code that converts the old style enums to new > style bit masks in some tapset variable. > > > - FChE I was thinking about an alternative that converted the fault number into a string, similar to the errno_str function in the errno.stp. function vm_fault_str(long:fault_no) Multiple bits would be separated with |. Thus, vm_fault_str(0xc) would return "VM_FAULT_MAJOR|VM_FAULT_WRITE" -Will