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: <ba4215e10906111045yf7288fbt4495d4dc96217d65@mail.gmail.com>
Date:	Thu, 11 Jun 2009 19:45:07 +0200
From:	Martin Fuzzey <mfuzzey@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Nicolas Pitre <nico@....org>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

On Thu, Jun 11, 2009 at 6:52 PM, Ben Hutchings<bhutchings@...arflare.com> wrote:
> It's an example of providing a generic solution, which is definitely
> more than a quick hack, but I don't see it as a "clean solution" for the
> problem that certain link modes don't work on a particular board.  A
> clean solution would disable those modes altogether in the driver.
>
I don't see why this is cleaner.
It may be slightly safer as someone can't later run ethtool and mess things up.

And how do you propose disabling it in the driver?
Either we're back to quick driver specific hacks  (which is what I
initially did before writing this patch) or we need a new in kernel
interface to be implemented by all the network drivers to filter their
capabilities.

The problems with the quick hack approach are:
1) Different for each driver
2) Need to understand how each driver works to do it
3) Need to maintain the driver patch against evolving kernel

And all this work will be done again and again by everyone that has
this problem.

OTOH adding a new interface to all the drivers is a "one off" effort
but _much_ more intrusive than my patch.
As we are arguing over if its worth adding a patch which requires zero
driver modifications and has zero impact for those that chose not to
enable it I don't see how adding a new interface to all the network
drivers just to meet the needs  of a few embedded people would ever be
accepted...

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