container_of in systemtap scripts

container_of in systemtap scripts

[Andi Kleen]

Hi,

systemtap 1.1 works nicely.

But I find myself writing embedded C when I need container_of(), which 
is needed to access more and more data structures in the kernel.

The code to do that looks rather ugly unfortunately.

@cast doesn't support that. Are there any other clean ways
to write container_of() natively or are there plans to extend cast to include
an offset?

Thanks,

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: container_of in systemtap scripts

[Frank Ch. Eigler]

Andi Kleen <andi@firstfloor.org> writes:

> systemtap 1.1 works nicely.

Thanks for trying it.

> [...]  @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.

- FChE

Re: container_of in systemtap scripts

[Josh Stone]

On 01/18/2010 07:04 AM, Frank Ch. Eigler wrote:
> Andi Kleen <andi@firstfloor.org> writes:
> 
>> systemtap 1.1 works nicely.
> 
> Thanks for trying it.
> 
>> [...]  @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.

Josh

Re: container_of in systemtap scripts

[Przemysław Pawełczyk]

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"])

Looks rather clear and also supports imaginable chaining. After all,
syntax is a secondary thing here.

Regards.

-- 
Przemysław Pawełczyk

Re: container_of in systemtap scripts

[Mark Wielaard]

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.

My 0.01 euro,

Mark

Re: container_of in systemtap scripts

[Przemysław Pawełczyk]

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

Re: container_of in systemtap scripts

[Andi Kleen]

> 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 agreed having a specialized function for this would be probably best,
preferable over syntactic vingear for @cast.

It's used often enough that it deserves an own function.

BTW some builtin helpers for list_heads would be also nice, these
are nearly everywhere these days too.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.