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]

Message-ID: <ba4215e10906120519o35358caducfdd253c9f8d8bd2@mail.gmail.com>
Date:	Fri, 12 Jun 2009 14:19:11 +0200
From:	Martin Fuzzey <mfuzzey@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	bhutchings@...arflare.com, nico@....org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

On Fri, Jun 12, 2009 at 2:09 AM, David Miller<davem@...emloft.net> wrote:

> You can instantiate a platform_device that the driver matches
> and uses to acquire board-specific-juju such as link modes
> which are non-functional.
>
Just to make sure I'm understanding you here - that would still
require modifying each and every network driver to use and interpret
the said platform_device right?
This proposal doesn't require _any_ changes to the network device drivers.
It also doesn't have _any_ impact on the kernel for those that don't enable it.

The smc9x driver contains this comment :
/*
 * The internal workings of the driver.  If you are changing anything
 * here with the SMC stuff, you should have the datasheet and know
 * what you are doing.
 */
Before writing this patch I had to disregard this to do the hacked version.
I wasn't touching the driver to improve it or fix it - in which case
it would be quite reasonable to expect me to have read the datasheet
but just to turn off a bit of functionality to work around broken
hardware.

Why should people have to dabble in driver internals just to say
"please use this mode"?
The proposed patch allows you to do this in a portable way so that
when you work on another board with a different network chip you don't
need to do it all again.

I thought I'd done everything right;I posted a question on the mailing
list, _before_ writing any code, discussion ensued and we seemed to
reach a consensus as when Nicolas proposed this solution you said:

>And you could even write it and maintain it somewhere if you
>like for other embedded people to use. :-)
>Once full featured, I'd be happy to include it.

So I went off and implemented it.
I'm not claiming  it's perfect but we're not even discussing the
implementation and how to improve it but have gone back to discussing
if we should even be doing it. This is _very_ fusttrating

Martin
--
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