From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96964 invoked by alias); 14 Feb 2017 18:00:48 -0000 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 Received: (qmail 96292 invoked by uid 89); 14 Feb 2017 18:00:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=deb, DEB, HTo:U*dsmith, H*i:sk:481a3f0 X-HELO: mail-wr0-f178.google.com Received: from mail-wr0-f178.google.com (HELO mail-wr0-f178.google.com) (209.85.128.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Feb 2017 18:00:44 +0000 Received: by mail-wr0-f178.google.com with SMTP id i10so175743502wrb.0 for ; Tue, 14 Feb 2017 10:00:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=S/iDjLTH20sNDJ4gHm78pHS3XO78Cc+wloK49pSWoa4=; b=sAZ0cOaHNPxF2GMoDeFwXZGyG5vheAdXLdRIn3aYSHZFSsoFKRgcQdQuBtfOp9QbTb VfMQ9MCxmrJsFFwb6lcl1Iwm3v6zIAM6eM4uuYUksidC2vV2/7tJdk5xYxtwwEXXj4qn 9ya2HhfWW3AaB4lXDaBiFS2gyMrBHsaZI/lzWMsgRqy1subpYsSMj3nGi6bqiokTNV/q T6bmRz8gwZW0ch8eRxYD2f5XgN3JVfUDclFW/PVjf+xW6uTnw487HTPXCutPV6oraubJ SRIOCdMsMyRlonsfKt8yUXMVd9lVPRBJCl63g+I65+PCvsdxlrCc3GetPdRDiYGNcMXL exRA== X-Gm-Message-State: AMke39m5DGucXqEHzQZm6/ltjrY4NXjAywMndK+CtPbQSuuqKUfFWSl+AVeNqhYLYpG6TJE60geOUegonpQqdA== X-Received: by 10.223.163.199 with SMTP id m7mr25140937wrb.63.1487095242807; Tue, 14 Feb 2017 10:00:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.166.156 with HTTP; Tue, 14 Feb 2017 10:00:22 -0800 (PST) In-Reply-To: <481a3f01-df14-ff12-833e-eeb707fa5256@redhat.com> References: <481a3f01-df14-ff12-833e-eeb707fa5256@redhat.com> From: Arkady Date: Tue, 14 Feb 2017 18:00:00 -0000 Message-ID: Subject: Re: Is there a roadmap for the STAP development? To: David Smith Cc: systemtap@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-q1/txt/msg00102.txt.bz2 On Tue, Feb 14, 2017 at 6:13 PM, David Smith wrote: > On 02/14/2017 12:51 AM, Arkady wrote: >> Hi, >> >> I am considering some patches for SystemTap - mostly fixing minor >> inconveniences. Obviously I would like to align the efforts and, >> hopefully merge the patches into the master. Is there a document >> describing the SystemTap development roadmap? > > Hmm, not that I know of. Some items of future development are tracked as > enhancements in sourceware's bugzilla. > >> Examples of things I would like to extend >> >> * Add build only flag in the stap utility which does not require root privileges > > Different from '-p4'? Yes, -p4 does the trick. I missed it. > >> * Add RPM spec file supporting automatic build of the kernel driver >> after kernel updates > > What do you mean by "the kernel driver"? I need to build the module automatically every time the kernel updates. I am preparing the RPM/DEB which does the trick, but to have a generic example in /docs/examples would be nice or even a script which generates such RPM based on the stap command line options. > >> * In the _stp_reserve_bytes() return indication that the trace buffer >> is overwritten >> * Add support for zero copy data transfer > > You'd have to flesh those last two items out a bit for me to understand > what you are looking to do. When I send the events from the stap module to the user space I am doing event_type* event = _stp_reserve_bytes(sizeof(event_type)); event->field1 = value1; ..... I do not handle case when _stp_reserve_bytes() starts to overwrite the data in the trace buffer. It would be cool to have some feedback that buffer is full or is getting full. In some situations it is better to drop the event and avoid overwriting the buffer. In another approach I am planning to use the shared memory for sending events from the kernel to the user space in one specific case - very frequent system calls. Similarly to transport.c with zero copy API. > > -- > David Smith > dsmith@redhat.com > Red Hat > http://www.redhat.com > 256.217.0141 (direct) > 256.837.0057 (fax)