* 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).