lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 4 Sep 2020 13:37:53 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sunil Kovvuri Goutham <sgoutham@...vell.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "sundeep.lkml@...il.com" <sundeep.lkml@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>
Subject: Re: [EXT] Re: [net-next PATCH 0/2] Introduce mbox tracepoints for
 Octeontx2

On Fri, 4 Sep 2020 12:29:04 +0000 Sunil Kovvuri Goutham wrote:
> > >No, there are 3 drivers registering to 3 PCI device IDs and there can
> > >be many instances of the same devices. So there can be 10's of instances of  
> > AF, PF and VFs.
> > 
> > So you can still have per-pci device devlink instance and use the tracepoint
> > Jakub suggested.
> >   
> 
> Two things
> - As I mentioned above, there is a Crypto driver which uses the same mbox APIs
>   which is in the process of upstreaming. There also we would need trace points.
>   Not sure registering to devlink just for the sake of tracepoint is proper. 
> 
> - The devlink trace message is like this
> 
>    TRACE_EVENT(devlink_hwmsg,
>      . . .
>         TP_printk("bus_name=%s dev_name=%s driver_name=%s incoming=%d type=%lu buf=0x[%*phD] len=%zu",
>                   __get_str(bus_name), __get_str(dev_name),
>                   __get_str(driver_name), __entry->incoming, __entry->type,
>                   (int) __entry->len, __get_dynamic_array(buf), __entry->len)
>    );
> 
>    Whatever debug message we want as output doesn't fit into this.

Make use of the standard devlink tracepoint wherever applicable, and you
can keep your extra ones if you want (as long as Jiri don't object).

Powered by blists - more mailing lists