netdev - Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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