netdev - Re: [PATCH 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs

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:	Thu, 06 May 2010 00:25:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	s-jan@...com
Cc:	netdev@...r.kernel.org, linux-omap@...r.kernel.org,
	x0066660@...com, ben-linux@...ff.org, Tristram.Ha@...rel.com
Subject: Re: [PATCH 4/4 v2] ks8851: read/write MAC address on companion
 eeprom through debugfs

From: Sebastien Jan <s-jan@...com>
Date: Wed,  5 May 2010 20:45:55 +0200

> A more elegant alternative to ethtool for updating the ks8851
> MAC address stored on its companion eeprom.
> Using this debugfs interface does not require any knowledge on the
> ks8851 companion eeprom organization to update the MAC address.
> 
> Example to write 01:23:45:67:89:AB MAC address to the companion
> eeprom (assuming debugfs is mounted in /sys/kernel/debug):
> $ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom
> 
> Signed-off-by: Sebastien Jan <s-jan@...com>

Elegant?  This commit message is the biggest lie ever told.

What makes your ethernet driver so god-damn special that it deserves
to have a private, completely unique, and obscure interface for
setting the permanent ethernet address of a network device?

Tell me how damn elegant it is that users have to learn about this
special, unique, and common with no other driver, interface for
performing this task?

Tell me how damn elegant it is when another driver wants to provide
users with a way to do this too, and they (like you) come up with
their own unique and different interface for doing this.

No, this is the most inelegant patch ever conceived because it totally
ignores the way in which we handle issues like this.

There is no way in the world I'm applying this garbage patch, sorry.

We have an ETHTOOL_GPERMADDR, add a new ETHTOOL_SPERMADDR operation
and then any driver (not just your's) can portably provide this
facility and users will have one, and only one, way of performing this
task.
--
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