public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ranty@debian.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: firmware separation filesystem (fwfs)
Date: Thu, 17 Apr 2003 00:46:31 +1000	[thread overview]
Message-ID: <20030416144631.GB899@zax> (raw)
In-Reply-To: <1050492681.28586.39.camel@dhcp22.swansea.linux.org.uk>

On Wed, Apr 16, 2003 at 12:31:21PM +0100, Alan Cox wrote:
> How is this better than simply having your hotplug helper load
> the firmware from disk ? Its nice code but you have to ask the
> question "why". I don't want the firmware wasting ram, I don't
> need the firmware fs wasting ram. I may need to load the right
> firmware from a choice of 16 odd types (usb_serial has some
> examples there).

The obvious case is where it's impossible, or at least difficult/messy
for userspace to directly access the device to upload the firmware.
The latter is the case for the orinoco devices: the same firmwares can
be used by USB, PCMCIA and PCI devices - these all have somewhat
different register configurationss and different upload methods.
Having an upload program that handles all these cases (not to mention
endian and IO vs. memory mapped registers) seems silly when the driver
already knows how to talk to the devices properly (actually we don't
do firmware upload yet, but one day).  

The driver could provide a chardev interface to upload the firmware
through, but that's a lot more work - and there are issues of mapping
the right chardev to the right network device instance, coping with
the device in half-alive mode (i.e. initialized enough that firmware
can be uploaded, but not ready to use because there's no firmware yet)
etc.

I believe the idea is that hotplug (or other scripts) would copy the
appropriate firmware into the relevant path in fwfs, so you don't need
RAM for every firmware variant - just the one you're using.  And if
we're really worried about memory it shouldn't be hard for the driver
to arrange to unlink the firmware image once it's done with it (at the
cost of not being able to reload the firmware on a reset/reinitialize,
which might be sensible or necessary for some devices).

My personal feeling is that this would probably make more sense as a
type of sysfs node, rather than a separate filesystem, but the basic
concept seems sound.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

  reply	other threads:[~2003-04-16 14:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-16  0:57 firmware separation filesystem (fwfs) Manuel Estrada Sainz
2003-04-16 11:31 ` Alan Cox
2003-04-16 14:46   ` David Gibson [this message]
2003-04-16 16:36     ` Manuel Estrada Sainz
2003-04-16 15:47       ` Alan Cox
2003-04-16 16:57         ` Riley Williams
2003-04-17 13:43           ` Alan Cox
2003-04-17 13:43           ` Alan Cox
2003-04-17  1:23         ` David Gibson
2003-04-17 13:12           ` Alan Cox
2003-04-19 20:41             ` Manuel Estrada Sainz
2003-04-19 21:52               ` Alan Cox
2003-04-20 19:26                 ` Manuel Estrada Sainz
  -- strict thread matches above, loose matches on Subject: below --
2003-04-17  0:17 Perez-Gonzalez, Inaky
2003-04-17  2:00 Perez-Gonzalez, Inaky
2003-04-17  3:31 ` Manuel Estrada Sainz
2003-04-17  4:06   ` Greg KH
2003-04-17  3:48 ` 'David Gibson'
2003-04-17  4:07 Perez-Gonzalez, Inaky

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=20030416144631.GB899@zax \
    --to=david@gibson.dropbear.id.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ranty@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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