Re: missing SDT_PROVIDER_DEFINE(sdt)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Apr 04, 2016 at 02:59:38AM +0000, Taylor R Campbell wrote:
> 
> If it's for Solaris compatibility, then maybe it is worthwhile to have
> an `sdt' provider so that we might expect to get more useful D scripts
> from the Solaris world.  (But that's something Someone^TM needs to
> actively work on, which evidently at least I haven't had the
> activation energy for.)

I wrote a number of static providers while I was at Coyote Point,
where Darran Hunt originally did the DTrace work for NetBSD.  I never
saw any point to defining a single "sdt" provider -- it's a flat,
catch-all namespace beneath which you'd have to know the name of
every probe to do anything useful.

Its sole purpose might be to give loadable kernel modules like ipfilter
which don't want to define their own top-level namespace (or can't?  I
don't remember how that part of the attach mechanism works, particularly
on Solaris) a place to hook up their static trace points.

For our code at CP, we defined providers for each of our own subsystems
which named things in what seemed like a sensible way, used fbt for the
rest, and left "sdt" basically unused.  I assume that's why it's how it
is in the public NetBSD sources today.

Using "sdt" for Solaris script compatibility would require defining the
same trace points it does.  Since sdt is generally used to expose
sub-function-level code structure or detailed datastructure of something
fbt can't get at for you... that would be a huge amount of compat work
for limited payoff.

-- 
  Thor Lancelot Simon	                                     tls%panix.com@localhost

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart