[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190115095352.75661db4@cakuba.netronome.com>
Date: Tue, 15 Jan 2019 09:53:52 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
oss-drivers@...ronome.com
Subject: Re: [RFC iproute2-next] devlink: add info subcommand
On Tue, 15 Jan 2019 09:20:11 +0100, Jiri Pirko wrote:
> > static void help(void)
> > {
> > pr_err("Usage: devlink [ OPTIONS ] OBJECT { COMMAND | help }\n"
> > " devlink [ -f[orce] ] -b[atch] filename\n"
> >- "where OBJECT := { dev | port | sb | monitor | dpipe | resource | region }\n"
> >+ "where OBJECT := { dev | port | sb | monitor | dpipe | resource | region | info }\n"
>
> I think that "info" should be nested under "dev". It is related to dev.
Ack.
> Maybe it even does not have to be a separate command and can be a nested
> attribute to existing DEVLINK_CMD_GET cmd.
I thought about that, but I'd rather keep it as a separate command.
I think it'd be good to keep DEVLINK_CMD_GET nice and lean.
For versions there may be FW communication required, and reading stuff
out of flash. I bit of overhead for users who just want the list of
devlink instances.
Having in under dev but as a separate command seems quite nice indeed.
Especially given that there can only be a show subcommand.. So:
For dump:
$ devlink dev info
But for get:
$ devlink dev pci/0000:82:00.0 info
or
$ devlink dev info pci/0000:82:00.0
?
Powered by blists - more mailing lists