| 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: <20090613.010712.100174619.davem@davemloft.net> Date: Sat, 13 Jun 2009 01:07:12 -0700 (PDT) From: David Miller <davem@...emloft.net> To: mfuzzey@...il.com Cc: bhutchings@...arflare.com, nico@....org, netdev@...r.kernel.org Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration. From: Martin Fuzzey <mfuzzey@...il.com> Date: Sat, 13 Jun 2009 09:51:38 +0200 > David Miller wrote: >> But the situation is different, the physical hardware has a limitation >> and know of this belongs, or should be described, in the driver >> somehow. >> > Theoretically I agree. However the only practical advantage I can see of > doing it in the driver is that it is then impossible to later re-enable > broken modes. The bug is a hardware limitation. The kernel programs and knows the hardware. Therefore knowledge of the limitation belongs in the kernel. In no other situation would we say "this aspect of this chip doesn't work, so we'll block usage of that in some high level configuration framework" No, we'd always deal with HW problems in the driver itself. You'd only re-enable the broken modes later when you know they are working properly, in which case you can update the driver as appropriate. And this is what we'd do in other similar cases too. -- 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