Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: awKGXHnh13QyC5cfCE+8TPKXgwiJkKUKtdJIDYDWy4lSL9c6XVKtxJXhUabfRfwrw4Bosa6AOF
 v7dJRkqSuQOe8bfiQinDgAjRM3T+KhaVBfWN030YE+rX5lk3RFC5kVTjxQP8d7Noe2UI8JdxTM
 6Yw/xPQ46Sxd/5tlZUhVS1DApM9nkQkwMk0AAXDmlyFoQr2CQO4EEoJGcJMAzR4QdUHWi6lIcO
 JlMQBkf+tVzBpY5bXlvruhveIAVYz/OLhz9tMurL+iEbfL/LfgMdV/17rOSuaBS4JnCOOR2zVk
 ee8=
From:   Avri Altman <Avri.Altman@wdc.com>
To:     Steven Rostedt <rostedt@goodmis.org>
CC:     Bean Huo <huobean@gmail.com>,
        "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "beanhuo@micron.com" <beanhuo@micron.com>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate
 among CDB, OSF, and TM
Thread-Topic: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate
 among CDB, OSF, and TM
Thread-Index: AQHWy+7VP58/cpTtqkiyF4OIctzYqqnrRKJQgACBJQCAAA6aAIAAEBuAgAD0GPA=
Date:   Tue, 8 Dec 2020 08:03:48 +0000
Message-ID: <DM6PR04MB6575864DCED7720950302244FCCD0@DM6PR04MB6575.namprd04.prod.outlook.com>
References: <20201206164226.6595-1-huobean@gmail.com>
        <20201206164226.6595-4-huobean@gmail.com>
        <DM6PR04MB6575197B8626D3F91C9231C4FCCE0@DM6PR04MB6575.namprd04.prod.outlook.com>
        <20201207103708.66897ef3@gandalf.local.home>
        <DM6PR04MB6575CD229D3F6E1C1B30B11EFCCE0@DM6PR04MB6575.namprd04.prod.outlook.com>
 <20201207122703.0190adf9@gandalf.local.home>
In-Reply-To: <20201207122703.0190adf9@gandalf.local.home>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 733f6de5-82ef-4cc3-c7d2-08d89b4fcb5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 08:03:48.8237
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0nsg16azBKznjAtcJHBSj5r3EncaAtyt5/xScMVlwPkogDJOrgDmDLfBABKzvPHbTFbA2rP3hetTgCw3GNgmdg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB4555
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>=20
> On Mon, 7 Dec 2020 16:40:51 +0000
> Avri Altman <Avri.Altman@wdc.com> wrote:
>=20
> > >
> > > On Mon, 7 Dec 2020 07:57:27 +0000
> > > Avri Altman <Avri.Altman@wdc.com> wrote:
> > >
> > > > >
> > > > >         TP_printk(
> > > > > -               "%s: %s: HDR:%s, CDB:%s",
> > > > > +               "%s: %s: HDR:%s, %s:%s",
> > > > >                 __get_str(str), __get_str(dev_name),
> > > > >                 __print_hex(__entry->hdr, sizeof(__entry->hdr)),
> > > > > +               __get_str(tsf_type),
> > > > This breaks what current parsers expects.
> > > > Why str is not enough to distinguish between the command?
> > >
> > > Hopefully it shouldn't. Reading from user space should use the
> > > libtraceevent library, that reads the format files and extracts the r=
aw
> > > data to find the fields. As long as the field exists, it should not b=
reak
> > > user space parsers. If it does, please let me know, and I'll gladly h=
elp
> > > change the user space code to use libtraceevent :-)
> > Hi Steve,
> > Thanks. I wasn't aware of libtraceevent - is this a new thing?
>=20
> Actually, it's been around almost as long as ftrace. But unfortunately,
> it's just now becoming a separate library. It was originally developed fo=
r
> trace-cmd, but has been copied into perf, power-top and rasdaemon. But
> this
> copying is inefficient and a maintenance nightmare, and we finally have t=
he
> library as a stand alone, and hopefully will be delivered by distribution=
s
> (I believe they are packaging it).
>=20
>    https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
>=20
> Looks like distros are starting to catch on.
>=20
>   https://packages.debian.org/unstable/libtraceevent-dev
>=20
>=20
> We are currently working on libtracefs
>=20
>   https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
>=20
> Which will make it a lot easier for applications to interact with the
> tracefs file system. I'm hoping to have this ready for distros by the end
> of the year. We have applications coming that depend on these.
>=20
> >
> > We have a relatively sophisticated analysis platform that utilizes raw =
traces,
> > Among which the upiu trace is the most important and informative.
> >
> > This tool has evolved over the years, adding more and more parsers per
> need,
> > and the users are picking the appropriate parser per the trace they use=
d.
> >
> > We will surely be glad to adopt new tracing capabilities,
>=20
> I think libtraceevent and libtracefs would be a much welcome addition for
> upiu trace as it would be reading raw data (very fast), and have an API
> that makes doing so much simpler. For example, I just wrote a quick progr=
am
> that checks what files an application opens (this is not in anyway
> production ready):
>=20
>   http://rostedt.org/code/show-open-files.c
>=20
> > But we would prefer not to break anything.
>=20
> Of course!
>=20
> And again, I would be happy to help out in converting to this libraries. =
It
> will make your applications more robust, as they make it so that you do n=
ot
> need to rely on the order of fields.
>=20
> Note, there's plans on making these libraries python modules as well (to
> have python scripts enable and read ftrace data).
Thanks a lot for your insightful comments.
We will surely look into libtraceevent and libtracefs

Thanks,
Avri
>=20
> -- Steve