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-next>] [day] [month] [year] [list]
Message-ID: <48592192.6060501@garzik.org>
Date:	Wed, 18 Jun 2008 10:54:10 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Jaswinder Singh <jaswinder@...radead.org>
CC:	kernelnewbies@...linux.org, kernel-janitors@...r.kernel.org,
	dwmw2@...radead.org, David Miller <davem@...emloft.net>,
	NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH] firmware: convert tg3 driver to request_firmware()

Jaswinder Singh wrote:
> Firmware blob is big-endian starts with version numbers, 
> followed by start address and length. 
> length = end_address_of_bss - start_address_of_text.
> Remainder is the blob to be loaded contiguously from start address.
> 
> Signed-off-by: Jaswinder Singh <jaswinder@...radead.org>
> --
> drivers/net/Kconfig              |    8
> drivers/net/tg3.c                |  782 ++++-----------------------------------
> drivers/net/tg3.h                |    4
> firmware/Makefile                |    2
> firmware/WHENCE                  |   19
> firmware/tigon/tg3.bin.ihex      |  175 ++++++++
> firmware/tigon/tg3_tso.bin.ihex  |  446 ++++++++++++++++++++++
> firmware/tigon/tg3_tso5.bin.ihex |  252 ++++++++++++
> 8 files changed, 992 insertions(+), 696 deletions(-)
> create mode 100644 firmware/tigon/tg3.bin.ihex
> create mode 100644 firmware/tigon/tg3_tso.bin.ihex
> create mode 100644 firmware/tigon/tg3_tso5.bin.ihex

Sigh, this has the same problems as the last patch.

* the Kconfig for the firmware should default to 'Y', to make it harder 
for users to create a non-working driver.

* request_firmware() capability is clearly and obviously a separate 
logical change, and should not be included in the same patch as firmware 
separation.

It just makes the patch longer and more difficult to read and review 
with the two separate changes mushed together.  Having separate patches 
also means it is easier to test and validate the loadable firmware approach.

* the firmware should live in the same dir as the driver, just like it 
has for its entire lifetime until now.  It's silly to create a driver 
hierarchy in firmware/ that parallels the rest of the tree

* fedora-rawhide, debian-unstable, and similar targets must already be 
prepped for firmware installs (both from the kernel and via external 
firmware packages like ipw2200-firmware).

* all net driver patches should get copied to netdev@...r.kernel.org, 
which is where networking changes are discussed


This patch should not create ANY operational differences for users. 
Requiring additional steps such as "make firmware_install" in order for 
the user to achieve the same working driver as they had in the last 
kernel is an example of such a [script-breaking] operational difference.

We have to make it tough for users to screw this up.  It's too easy to 
create a non-working driver, with request_firmware()...   as existing 
distro support for firmwares has already proven in the field.

	Jeff


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ