From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760345AbZDQKER (ORCPT ); Fri, 17 Apr 2009 06:04:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758230AbZDQKEE (ORCPT ); Fri, 17 Apr 2009 06:04:04 -0400 Received: from fk-out-0910.google.com ([209.85.128.185]:54593 "EHLO fk-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757101AbZDQKEC convert rfc822-to-8bit (ORCPT ); Fri, 17 Apr 2009 06:04:02 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TBJMK6gxRwhVrTvYx5fW0+AVQncqYFLrPdxfXBgaXcLTe1CntpP5UOq+2qPWdwdaIF YLWyGklwYDGVtK8CKzccKOK+G1Uq2WlANEBKGMpfJiGhNTkJKqETTvP0BdOpxcxCmSqb 0WHuLy8DDjBtoOJZbP4+MCujFYFDb4qG5heos= MIME-Version: 1.0 In-Reply-To: <1239960548.23397.4282.camel@laptop> References: <1239912047-6282-1-git-send-email-fweisbec@gmail.com> <1239912812.23397.3432.camel@laptop> <1239949360.23397.4065.camel@laptop> <1239960548.23397.4282.camel@laptop> Date: Fri, 17 Apr 2009 12:04:00 +0200 Message-ID: Subject: Re: [PATCH 1/2 v2] tracing/events: provide string with undefined size support From: =?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?= To: Peter Zijlstra Cc: Ingo Molnar , Steven Rostedt , Zhaolei , Tom Zanussi , Li Zefan , KOSAKI Motohiro , LKML Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 17 avril 2009 11:29, Peter Zijlstra a écrit : > On Fri, 2009-04-17 at 10:59 +0200, Frédéric Weisbecker wrote: > >> struct foo { >> field1; >> field2; >> ... >> }; >> >> struct foo *f; >> >> event = ring_buffer_lock_reserve(sizeof(*f), ...); >> f = ring_buffer_event_data(event); >> >> I can't use a kmalloc here. We are tracing a random event which can happen >> at a random frequency, random context, etc... > > Can't you add a bit to that ring_buffer_lock_reserve() thing? > > The thing I do for perf_counters is I first iterate all the output, then > make the reserve large enough to fit all the output in, then copy the > bits into the output buffer. > > The result is that the output cannot be interpreted as a fixed offset > struct, but that's not much of an issue anyway. > > Another possibility is using relative pointers for strings that point > beyond the tail of the fixed offset struct. > > So something like: > > __field(int, foo); > __string(bar); > __field(int, foo2); > __string(bar2); > __field(int, foo3); > > would look like: > > struct plop { > int foo; > char *bar; > int foo2; > char *bar2; > int foo3; > > char data[0]; > } > > and you'd do something like: > > size = sizeof(struct plop); > size += strlen(bar) + 1; > size += strlen(bar2) + 1; > > event = ring_buffer_lock_reserve(size); > offset = sizeof(struct plop); > my_plop.bar = (char *)offset; > offset += strlen(bar) + 1; > my_plop.bar2 = (char *)offset; > memcpy(&event, &my_plop, sizeof(struct plop)); > memcpy(&event + my_plop.bar, bar, strlen(bar)+1); > memcpy(&event + my_plop.bar2, bar2, strlen(bar2)+1); > ring_buffer_unlock(); > > Then on reading, you'd get a variable sized entry, with a fixed size > fixed offset struct, that contains relative offset character pointers. I like much this idea. Just a small change on it: I could use absolute addresses offset = sizeof(struct plop); my_plop.bar = &entry + offset; offset += strlen(str1) + 1; my_plop.bar2 = &entry + offset; strcpy(my_plop.bar, str1); strcpy(my_plop.bar2, str2); So that its integration will need very few changes to support printing and filtering. It will just behave like usual char [..]. Nice! Thanks Peter.