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: <1342444134.2523.4.camel@bwh-desktop.uk.solarflarecom.com> Date: Mon, 16 Jul 2012 14:08:54 +0100 From: Ben Hutchings <bhutchings@...arflare.com> To: Jean Delvare <jdelvare@...e.de> CC: <netdev@...r.kernel.org>, Tim Hockin <thockin@...kin.org>, Olaf Kirch <okir@...e.de> Subject: Re: [PATCH] natsemi: make cable length magic configurable On Mon, 2012-07-16 at 14:26 +0200, Jean Delvare wrote: [...] > > You would need to: > > 1. Number the flags starting from 0. Well, that was easy. > > 2. Implement {get,set}_priv_flags() operations to access all flags as > > a bitmask. > > 3. Expose the flag names as string set ETH_SS_PRIV_FLAGS accessed by > > get_sset_count() and get_strings() operations. > > I was looking for an example, but there doesn't seem to be any driver > implementing private flags at the moment? No. > I am also unsure if a private flag is a suitable solution to the problem > at hand. I am a little worried about the timing, as the non-default > value can't be set before the network device is available, I'm afraid > the network initialization scripts may kick in before one has a chance > to set the flag with ethtool. I suppose this could be problematic, but > then again I don't know much about network device drivers, I don't even > know for sure when method .ndo_open is called... It's called when the interface is brought up (ifconfig up, ip link set up, start NetworkManager...). Some distributions provide a configuration option(s) to run ethtool while bringing an interface up. > Furthermore I don't quite get why we can't just go with the module > parameter. As I understand it, this is a crappy driver for crappy, rare > hardware. The driver already has a module parameter to work around a > hardware bug (dspcfg_workaround), I don't quite see why adding a second > one would be a problem. At least it is consistent. David can be quite insistent about finding an alternative to module parameters. Ben. -- Ben Hutchings, Staff 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