[Intel-gfx] [RFC 2/3] lsgpu: User friendly device listing

[Zbigniew Kempczyński]

On Tue, Nov 10, 2020 at 11:20:46AM +0000, Tvrtko Ursulin wrote:
> 
> On 10/11/2020 11:03, Zbigniew Kempczyński wrote:
> > On Mon, Nov 09, 2020 at 10:48:10AM +0000, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > 
> > > New default user frindly device listing mode which replaces:
> > > 
> > > sys:/sys/devices/pci0000:00/0000:00:02.0/drm/card0
> > >      subsystem       : drm
> > >      drm card        : /dev/dri/card0
> > >      parent          : sys:/sys/devices/pci0000:00/0000:00:02.0
> > > 
> > > sys:/sys/devices/pci0000:00/0000:00:02.0/drm/renderD128
> > >     subsystem       : drm
> > >     drm render      : /dev/dri/renderD128
> > >     parent          : sys:/sys/devices/pci0000:00/0000:00:02.0
> > > 
> > > sys:/sys/devices/pci0000:00/0000:00:02.0
> > >     subsystem       : pci
> > >      drm card        : /dev/dri/card0
> > >      drm render      : /dev/dri/renderD128
> > >      vendor          : 8086
> > >      device          : 193B
> > > 
> > > With:
> > > 
> > > card0                   8086:193B    drm:/dev/dri/card0
> > > └─renderD128                         drm:/dev/dri/renderD128
> > > 
> > > Advantages are more compact, more readable, one entry per GPU.
> > > 
> > > Legacy format can be chose using the -s / --print-simple command line
> > > switches.
> > > 
> > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > > Cc: Petri Latvala <petri.latvala at intel.com>
> > > Cc: Zbigniew Kempczyński <zbigniew.kempczynski at intel.com>
> > > ---
> > >   tools/lsgpu.c | 10 ++++++++--
> > >   1 file changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/lsgpu.c b/tools/lsgpu.c
> > > index 2541d1c24e66..3b234b73361a 100644
> > > --- a/tools/lsgpu.c
> > > +++ b/tools/lsgpu.c
> > > @@ -70,6 +70,7 @@
> > >    */
> > >   enum {
> > > +	OPT_PRINT_SIMPLE   = 's',
> > >   	OPT_PRINT_DETAIL   = 'p',
> > >   	OPT_LIST_VENDORS   = 'v',
> > >   	OPT_LIST_FILTERS   = 'l',
> > > @@ -85,6 +86,7 @@ static char *igt_device;
> > >   static const char *usage_str =
> > >   	"usage: lsgpu [options]\n\n"
> > >   	"Options:\n"
> > > +	"  -s, --print-simple          Print simple (legacy) device details\n"
> > >   	"  -p, --print-details         Print devices with details\n"
> > >   	"  -v, --list-vendors          List recognized vendors\n"
> > >   	"  -l, --list-filter-types     List registered device filters types\n"
> > > @@ -151,6 +153,7 @@ static char *get_device_from_rc(void)
> > >   int main(int argc, char *argv[])
> > >   {
> > >   	static struct option long_options[] = {
> > > +		{"print-simple",      no_argument,       NULL, OPT_PRINT_SIMPLE},
> > >   		{"print-detail",      no_argument,       NULL, OPT_PRINT_DETAIL},
> > >   		{"list-vendors",      no_argument,       NULL, OPT_LIST_VENDORS},
> > >   		{"list-filter-types", no_argument,       NULL, OPT_LIST_FILTERS},
> > > @@ -160,12 +163,15 @@ int main(int argc, char *argv[])
> > >   	};
> > >   	int c, index = 0;
> > >   	char *env_device = NULL, *opt_device = NULL, *rc_device = NULL;
> > > -	enum igt_devices_print_type printtype = IGT_PRINT_SIMPLE;
> > > +	enum igt_devices_print_type printtype = IGT_PRINT_USER;
> > > -	while ((c = getopt_long(argc, argv, "pvld:h",
> > > +	while ((c = getopt_long(argc, argv, "spvld:h",
> > >   				long_options, &index)) != -1) {
> > >   		switch(c) {
> > > +		case OPT_PRINT_SIMPLE:
> > > +			printtype = IGT_PRINT_SIMPLE;
> > > +			break;
> > >   		case OPT_PRINT_DETAIL:
> > >   			printtype = IGT_PRINT_DETAIL;
> > >   			break;
> > > -- 
> > > 2.25.1
> > > 
> > 
> > Looks ok:
> > 
> > Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski at intel.com>
> 
> Thanks.
> 
> Any concerns about potential existence of tools which parse lsgpu output and
> may depend on the default format?
> 
> Regards,
> 
> Tvrtko

At the moment I don't know about any tool which parses lsgpu output. But if 
we provide switches which print specific user/simple/detail format we 
always can enforce tool to output in format we expect.
 
IMO more important are "stable" filters, I mean they should expect same 
syntax and provide same semantic.

--
Zbigniew