Re: [PATCH] fix alias cache breakage

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Tue, Jul 15, 2008 at 10:02:15AM -0500, James Bottomley wrote:
> [...]
> > Simply caching by module is fine.  We'd only need a "linked entity"
> > concept if we were to have an automated search path between these
> > per-module caches.
> 
> No ... it's a scoping thing ... we need to know which modules to search
> for a symbol.  [...]

> It sort of really sounds like an include keyword might be the best way.
> [...]
> include kernel
> include module("<module>")
> and simply populate the search list.

Maybe, except even the search list is different on a probe-by-probe
basis.  For type resolution, we will have the @cast() thing, perhaps
extended even more to specify multiple modules.  (The other place
where this kind of thing could help is for resolving $global variable
addresses in faraway CU's, but let's leave that for later.)

> [...] Hmm, so basically the language syntax for kernel vs user is
> always going to be different, so the pattern matchers always
> distinguish.  I suppose it's a but inelegant, but it makes it easy
> to separate the caches (just need a kernel cache and a user cache).

(FWIW, I don't want to use the word "cache" for this.)  When
performing type definition lookup, even userspace is not a homogenous
pool for those purposes.  A single systemtap script will be able to
probe multiple applications and libraries simultaneously.  libfoo's
and libbar's "struct baz" will in general be different.  Each probe
will have an initial context for address/typing searches (defined by
the elf object being probed), but if one needs to get beyond that,
"search all of known userspace" is not the right answer.

- FChE