From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19877 invoked by alias); 19 Jan 2010 09:53:12 -0000 Received: (qmail 19866 invoked by uid 22791); 19 Jan 2010 09:53:10 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from mail-pw0-f51.google.com (HELO mail-pw0-f51.google.com) (209.85.160.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jan 2010 09:53:06 +0000 Received: by pwj15 with SMTP id 15so2346653pwj.10 for ; Tue, 19 Jan 2010 01:53:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.5.18 with SMTP id h18mr1164915wai.177.1263894784626; Tue, 19 Jan 2010 01:53:04 -0800 (PST) In-Reply-To: <1263892866.2286.7.camel@hermans.wildebeest.org> References: <20100118131557.GA4127@basil.fritz.box> <4B54BCBA.6090002@redhat.com> <40e92d5b1001181239y4168b059l355ca07323f0c00c@mail.gmail.com> <1263892866.2286.7.camel@hermans.wildebeest.org> Date: Tue, 19 Jan 2010 09:53:00 -0000 Message-ID: <40e92d5b1001190153y631ae917vb7747ee85e61b74b@mail.gmail.com> Subject: Re: container_of in systemtap scripts From: =?UTF-8?Q?Przemys=C5=82aw_Pawe=C5=82czyk?= To: Mark Wielaard Cc: Josh Stone , "Frank Ch. Eigler" , Andi Kleen , systemtap@sources.redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 2010-q1/txt/msg00189.txt.bz2 2010/1/19 Mark Wielaard : > On Mon, 2010-01-18 at 21:39 +0100, Przemys=C5=82aw Pawe=C5=82czyk wrote: >> On Mon, Jan 18, 2010 at 20:55, Josh Stone wrote: >> > On 01/18/2010 07:04 AM, Frank Ch. Eigler wrote: >> >> Andi Kleen writes: >> >>> [...] =C2=A0@cast doesn't support that. Are there any other clean wa= ys to >> >>> write container_of() natively >> >> >> >> Actually it this sort of thing should work, since we have "&" operato= rs: >> >> >> >> @cast($subfieldptr - (& @cast(0, "struct container")->subfield), >> >> =C2=A0 =C2=A0 =C2=A0 "struct container") >> >> >> >>> or are there plans to extend cast to include an offset? >> >> >> >> Sure, we can do something like that if needed. >> > >> > The hardest part of such things is deciding on the syntax. =C2=A0Curre= ntly it >> > can be written: >> > >> > =C2=A0@cast(ptr, "type") >> > =C2=A0@cast(ptr, "type", "module") >> > =C2=A0@cast(ptr, "type", "
") >> > >> > I propose adding a qualifier on the type field, something like >> > "type->field" or "type:field". =C2=A0The former is consistent with how= fields >> > are specified elsewhere, but it may imply more flexibility than a >> > "container_of" can support. =C2=A0(e.g. "mystruct->foo->bar" could onl= y work >> > if there are no pointers in that chain.) =C2=A0The latter with a colon= looks >> > nice to me, but it introduces a new syntax. >> >> My syntax proposal for container_of equivalent in stap is following one: >> @cast(ptr, "type<-field"[, "module"]) > > Just for those that like me had to think twice before grokking the > actual semantics of container_of: http://kernelnewbies.org/MagicMacros > > The @cast extensions are clever. But if we want to support it directly > and introduce new syntax I think it makes sense to just have new "magic > @" syntax instead of reusing @cast. > @container_of(ptr, "type", "member" [, "module" | "
"]) > That keeps @cast simple as it is now, and when reading (kernel) sources > it makes transposing it into a stap script straightforward since the > syntax is almost identical. Yes, having @container_of would be useful for kernel hackers allowing straightforward transition, but I think, that we're also aiming at high readability of systemtap scripts. As you have already encountered, container_of isn't absolutely and totally obvious at first sight. IMHO @cast with "<-" is easier to grasp (but I'm possibly biased). Maybe we could have both, aliasing one to another? > My 0.01 euro, My 0.01 PLN. Regards. --=20 Przemys=C5=82aw Pawe=C5=82czyk