[DTrace-devel] [PATCH] reorder providers

[Kris Van Hees]

Actually, legacy dtrace never has had any predefined order for providers, other
than the order in which the kernel modules were loaded (which means dtrace
provider probes are always first anyway).  There is nothing that depends on the
order of providers and users should not depend on this order because it has
never been intended as being deterministic in any way.

I don't think there is any point in trying to implement any specific order.

On Fri, Mar 27, 2020 at 01:39:16PM -0400, eugene.loh at oracle.com wrote:
> From: Eugene Loh <eugene.loh at oracle.com>
> 
> This is a minor usability point, but the legacy ordering of providers
> -- e.g., the order in which probes were seen in "dtrace -l" output --
> was:
>   - dtrace
>   - profile
>   - syscall
>   - sdt-based; e.g.,
>         fc io ip iscsi lockstat nfsv3 nfsv4 perf
>         proc sched smb srp sysevent tcp udp xpv
>   - fbt
> 
> Change the order in the new implementation to conform to that legacy
> order because that legacy order:
> 
> *)  has some familiarity.
> 
> *)  has some merit.  Providers with fewer probes,
>     and arguably more common probes, appear earlier.
> 
> Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
> ---
>  libdtrace/dt_open.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libdtrace/dt_open.c b/libdtrace/dt_open.c
> index 6b0ba71d..aa1e97f1 100644
> --- a/libdtrace/dt_open.c
> +++ b/libdtrace/dt_open.c
> @@ -63,9 +63,9 @@ const dt_version_t _dtrace_versions[] = {
>   */
>  static const dt_provimpl_t *dt_providers[] = {
>  	&dt_dtrace,
> -	&dt_fbt,
> -	&dt_sdt,
>  	&dt_syscall,
> +	&dt_sdt,
> +	&dt_fbt,
>  };
>  
>  /*
> -- 
> 2.18.2
> 
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel