| 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: <20080708164826.2a2d52c2@infradead.org> Date: Tue, 8 Jul 2008 16:48:26 -0700 From: Arjan van de Ven <arjan@...radead.org> To: David Miller <davem@...emloft.net> Cc: swise@...ngridcomputing.com, rdreier@...co.com, shemminger@...tta.com, netdev@...r.kernel.org Subject: Re: Printing the driver name as part of the netdev watchdog message On Tue, 08 Jul 2008 14:57:38 -0700 (PDT) David Miller <davem@...emloft.net> wrote: > > What we need instead is to cache the info block into the netdev struct > when the driver is ->open()'d, and then you can fetch it out of > there however you like. but.. isn't that like almost the same as using the object model data at that point? > > Or, at least, that is one possible approach. I'll look at it; but this begs the question if this shouldn't turned inside out. I mean... if we had a "netdev_set_drivername()" thing with appropriate arguments (well I suck at names, name it whatever you feel like), we wouldn't need the drivers to implement each their own ethtool method, since this could just be done in one place and pull the data from the netdev. (for the eeprom etc data that's different, but those are already different ethtool methods last I looked) -- If you want to reach me at my work email, use arjan@...ux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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