Re: kernel dtrace and current

On Sun, Sep 13, 2015 at 08:53:33PM +0000, Mark Johnston wrote:

> On Sun, Sep 13, 2015 at 04:23:23PM +0300, Alexander V. Chernikov wrote:
> > Hello all,
> > 
> > I keep running in
> > "dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39: failed to copy type of 'pr_uid': Type information is in parent and unavailable"
> > message more and more often while trying to trace different -current kernels.
> > 
> > Typically the reason besides that is the number of types embedded in kernel CTF:
> > ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}'
> > 37160
> > 
> > We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/ highest bit set) are considered "child" types with the information stored in "parent").
> > ctfmerge ignores this fact and instead of yelling emits type indices above 32k. On the other hand, libctf sees such indices while parsing sections and since there is no
> > "parent" for kernel, it emits the error above and stops.
> > 
> > Thankfully, r287234 really improved the situation for ctfmerge, but there are still several thousands of identical structures and the total number is close to 32k.
> 
> r281797 and r287234 should have fixed most instances of duplicate type
> definitions. At the moment, amd64 GENERIC and GENERIC-NODEBUG have
> roughly 25K types in their respective CTF containers; there is a small
> handful of duplicates, but at least some of them are legitimate (some
> pairs of drivers redefine the same types, e.g. aac(4)/aacraid(4) or
> mps(4)/mpr(4)).
> 
> Could you post a config that results in the large number of duplicates
> you mention above?
> 
> > 
> > Personally I solved this by removing unneeded devices from GENERIC-inherited configs.
> > I wonder, however if this can be handled better.
> 
> FWIW, removing old drivers from GENERIC would be straightforward if we
> could auto-load KLDs based on device IDs.

We can just unconditionaly load all current drivers from GENERIC as
KLD. This is as good as ever.