public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik•org>
To: David Woodhouse <dwmw2@infradead•org>
Cc: e1000-devel@lists•sourceforge.net, netdev@vger•kernel.org,
	Auke Kok <auke-jan.h.kok@intel•com>,
	Jaswinder Singh <jaswinderlinux@gmail•com>
Subject: Re: [PATCH] firmware: convert e100 driver to request_firmware()
Date: Sun, 15 Jun 2008 19:30:31 -0400	[thread overview]
Message-ID: <4855A617.90006@garzik.org> (raw)
In-Reply-To: <1213567775.26255.534.camel@pmac.infradead.org>

David Woodhouse wrote:
> On Sun, 2008-06-15 at 14:44 -0400, Jeff Garzik wrote:
>> Each driver is _intimately_ tied to its firmware, so it only increases
>> headaches by separating two pieces of a single, cohesive whole.
> 
> On reflection, that argument _does_ make me inclined to modify my
> approach.
> 
> The _only_ thing that lets us justify the inclusion of this firmware
> blob in the kernel in the first place is the rather tenuous claim that
> it is "mere aggregation on a volume of a storage or distribution medium"
> -- as if it's just some kind of coincidence that these two pieces of
> work happen to be shipped together.
> 
> If they really are "intimately tied pieces of a single, cohesive whole",
> as you say, then the claim that it's "mere aggregation on a volume of a
> storage or distribution medium" loses whatever small amount of
> credibility it had in the first place, and we have no option but to
> remove the offending part immediately.
> 
> Revised patch follows....
> 
>  drivers/net/Kconfig |    1 
>  drivers/net/e100.c  |  281 +++++++++++++++-------------------------------------
>  2 files changed, 86 insertions(+), 196 deletions(-)

So, in response you separate them further?  No thanks.

Put the data in drivers/net/e100.firmware.  It makes no sense to have 
two parallel driver hierarchies, one for C source and one for firmwares.

And IMO I would think the best first step for all such drivers would be 
to add request_firmware() support _without_ touching the embedded 
firmware.  You are trying to stuff too much change into a single patch.

Such a step gets most of your driver modifications into the kernel with 
the least headache and controversy, while adding the quite-useful 
ability to have a driver load an external firmware instead of the 
embedded one.

request_firmware() infrastructure addition is clearly a separate and 
distinct change from moving/removing an embedded firmware.

	Jeff




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

      reply	other threads:[~2008-06-15 23:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-15  9:42 [PATCH] firmware: convert e100 driver to request_firmware() David Woodhouse
2008-06-15 17:50 ` Jeff Garzik
2008-06-15 17:51   ` David Woodhouse
2008-06-15 18:07     ` Jeff Garzik
2008-06-15 18:34   ` Jaswinder Singh
2008-06-15 18:42     ` David Woodhouse
2008-06-15 19:00       ` Jeff Garzik
2008-06-15 18:44     ` Jeff Garzik
2008-06-15 22:09       ` David Woodhouse
2008-06-15 23:30         ` Jeff Garzik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4855A617.90006@garzik.org \
    --to=jeff@garzik$(echo .)org \
    --cc=auke-jan.h.kok@intel$(echo .)com \
    --cc=dwmw2@infradead$(echo .)org \
    --cc=e1000-devel@lists$(echo .)sourceforge.net \
    --cc=jaswinderlinux@gmail$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox