* container_of in systemtap scripts
@ 2010-01-18 13:16 Andi Kleen
2010-01-18 15:04 ` Frank Ch. Eigler
0 siblings, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2010-01-18 13:16 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-18 13:16 container_of in systemtap scripts Andi Kleen
@ 2010-01-18 15:04 ` Frank Ch. Eigler
2010-01-18 19:55 ` Josh Stone
0 siblings, 1 reply; 7+ messages in thread
From: Frank Ch. Eigler @ 2010-01-18 15:04 UTC (permalink / raw)
To: Andi Kleen; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-18 15:04 ` Frank Ch. Eigler
@ 2010-01-18 19:55 ` Josh Stone
2010-01-18 20:39 ` Przemysław Pawełczyk
0 siblings, 1 reply; 7+ messages in thread
From: Josh Stone @ 2010-01-18 19:55 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: Andi Kleen, systemtap
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-18 19:55 ` Josh Stone
@ 2010-01-18 20:39 ` Przemysław Pawełczyk
2010-01-19 9:21 ` Mark Wielaard
0 siblings, 1 reply; 7+ messages in thread
From: Przemysław Pawełczyk @ 2010-01-18 20:39 UTC (permalink / raw)
To: Josh Stone; +Cc: Frank Ch. Eigler, Andi Kleen, systemtap
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-18 20:39 ` Przemysław Pawełczyk
@ 2010-01-19 9:21 ` Mark Wielaard
2010-01-19 9:53 ` Przemysław Pawełczyk
2010-01-19 12:41 ` Andi Kleen
0 siblings, 2 replies; 7+ messages in thread
From: Mark Wielaard @ 2010-01-19 9:21 UTC (permalink / raw)
To: Przemysław Pawełczyk
Cc: Josh Stone, Frank Ch. Eigler, Andi Kleen, systemtap
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-19 9:21 ` Mark Wielaard
@ 2010-01-19 9:53 ` Przemysław Pawełczyk
2010-01-19 12:41 ` Andi Kleen
1 sibling, 0 replies; 7+ messages in thread
From: Przemysław Pawełczyk @ 2010-01-19 9:53 UTC (permalink / raw)
To: Mark Wielaard; +Cc: Josh Stone, Frank Ch. Eigler, Andi Kleen, systemtap
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: container_of in systemtap scripts
2010-01-19 9:21 ` Mark Wielaard
2010-01-19 9:53 ` Przemysław Pawełczyk
@ 2010-01-19 12:41 ` Andi Kleen
1 sibling, 0 replies; 7+ messages in thread
From: Andi Kleen @ 2010-01-19 12:41 UTC (permalink / raw)
To: Mark Wielaard
Cc: Przemysław Pawełczyk, Josh Stone, Frank Ch. Eigler,
Andi Kleen, systemtap
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-01-19 12:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-18 13:16 container_of in systemtap scripts Andi Kleen
2010-01-18 15:04 ` Frank Ch. Eigler
2010-01-18 19:55 ` Josh Stone
2010-01-18 20:39 ` Przemysław Pawełczyk
2010-01-19 9:21 ` Mark Wielaard
2010-01-19 9:53 ` Przemysław Pawełczyk
2010-01-19 12:41 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).