This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: container_of in systemtap scripts
2010/1/19 Mark Wielaard <mjw@redhat.com>:
> On Mon, 2010-01-18 at 21:39 +0100, PrzemysÅaw PaweÅczyk wrote:
>> On Mon, Jan 18, 2010 at 20:55, Josh Stone <jistone@redhat.com> wrote:
>> > On 01/18/2010 07:04 AM, Frank Ch. Eigler wrote:
>> >> Andi Kleen <andi@firstfloor.org> writes:
>> >>> [...] Â@cast doesn't support that. Are there any other clean ways to
>> >>> write container_of() natively
>> >>
>> >> Actually it this sort of thing should work, since we have "&" operators:
>> >>
>> >> @cast($subfieldptr - (& @cast(0, "struct container")->subfield),
>> >> Â Â Â "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. ÂCurrently it
>> > can be written:
>> >
>> > Â@cast(ptr, "type")
>> > Â@cast(ptr, "type", "module")
>> > Â@cast(ptr, "type", "<header>")
>> >
>> > I propose adding a qualifier on the type field, something like
>> > "type->field" or "type:field". ÂThe former is consistent with how fields
>> > are specified elsewhere, but it may imply more flexibility than a
>> > "container_of" can support. Â(e.g. "mystruct->foo->bar" could only work
>> > if there are no pointers in that chain.) ÂThe 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" | "<header>"])
> 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.
--
PrzemysÅaw PaweÅczyk