| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1300488277.2589.50.camel@bwh-desktop> Date: Fri, 18 Mar 2011 22:44:37 +0000 From: Ben Hutchings <bhutchings@...arflare.com> To: Ajit.Khaparde@...lex.Com Cc: netdev@...r.kernel.org Subject: [PATCH ethtool] ethtool: Report driver features described in struct ethtool_drvinfo On Fri, 2011-03-18 at 15:07 -0700, Ajit.Khaparde@...lex.Com wrote: > ________________________________________ > From: Ben Hutchings [bhutchings@...arflare.com] > Sent: Friday, March 18, 2011 5:00 PM > To: Khaparde, Ajit > Cc: netdev@...r.kernel.org > Subject: RE: [RFC] ethtool: Display reg dump length via get driver info. > > > On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@...lex.Com wrote: > >> ______________________________________ > >> From: Ben Hutchings [bhutchings@...arflare.com] > >> Sent: Friday, March 18, 2011 4:32 PM > >> To: Khaparde, Ajit > >> Cc: netdev@...r.kernel.org > >> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info. > >> > >> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote: > >> >> Devices like BE store Reg Dump Data in the hardware. > >> > > >> Where else would it be? > >> > >> Well yes. That's true. > >> > >> >> This change will allow to just peek into the hardware > >> >> to see if any data is available for a dump and analysis, > >> >> without actually dumping the register data. > >> > [...] > >> > >> > This is wrong. ethtool_ops::get_regs_len really should return a > >> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of > >> > the right size. If the size of a dump really does vary then make it > >> > return the maximum possible size for the device. > >> > >> Yes, it is a constant size. And will always be the max size possible. > >> I just want to see if I can get the length, without really making the ethtoool -d call. > >> Because that will trigger the dump too. > >> At that moment, I may not be interested in the data itself. > > > OK, so what you're really interested in is 'does this version of the > > driver support register dump'? > > Yes. I did not want to add another option in ethtool to get this info out. So, how about this? Ben. --- ETHTOOL_GDRVINFO fills out struct ethtool_drvinfo with the size of the data returned by various other operations. The size should be non-zero if and only if the driver implements that operation. Therefore, we can report whether the driver supports certain operations without actually trying them (which may be expensive and disruptive). Do this in dump_drvinfo() rather than adding a separation operation. --- ethtool.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/ethtool.c b/ethtool.c index e9cb2c9..32df0ee 100644 --- a/ethtool.c +++ b/ethtool.c @@ -1423,11 +1423,19 @@ static int dump_drvinfo(struct ethtool_drvinfo *info) "driver: %s\n" "version: %s\n" "firmware-version: %s\n" - "bus-info: %s\n", + "bus-info: %s\n" + "supports-statistics: %s\n" + "supports-test: %s\n" + "supports-eeprom-access: %s\n" + "supports-register-dump: %s\n", info->driver, info->version, info->fw_version, - info->bus_info); + info->bus_info, + info->n_stats ? "yes" : "no", + info->testinfo_len ? "yes" : "no", + info->eedump_len ? "yes" : "no", + info->regdump_len ? "yes" : "no"); return 0; } --- -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists