mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Manuel Estrada Sainz <ranty@debian.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Simon Kelley <simon@thekelleys.org.uk>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Downing, Thomas" <Thomas.Downing@ipc.com>,
	Greg KH <greg@kroah.com>,
	jt@hpl.hp.com, Pavel Roskin <proski@gnu.org>
Subject: Re: request_firmware() hotplug interface, third round.
Date: Fri, 16 May 2003 15:13:52 +0200	[thread overview]
Message-ID: <20030516151352.D626@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <20030515200324.GB12949@ranty.ddts.net>; from ranty@debian.org on Thu, May 15, 2003 at 10:03:24PM +0200

Hi all,

On Thu, May 15, 2003 at 10:03:24PM +0200, Manuel Estrada Sainz wrote:
> 	
> 	- echo 1 > /sysfs/class/firmware/dev_name/loading
> 	- cat whatever_fw > /sysfs/class/firmware/dev_name/data
> 	- echo 0 > /sysfs/class/firmware/dev_name/loading
 
Why not doing that in open and require firmware data to contain
size information? Good firmware formats contain already size,
checksum and version information. Bad firmware can be wrapped to
get these. It should be made a requirement to contain at least a
size and a checksum.

To handle the big varieties of firmware formats, I would suggest
to either wrap all in user space or define 3 functions per
firmware format like the seq_file support. The thing is very
similiar, except that we read from user space instead of writing.

fw_begin_firmware_store()
fw_next_firmware_bytes()
fw_end_firmware_store()

fw_begin_firmware_store() gets at most a page of data and should
   evaluate from this data, how much bytes it still needs from
   user space. It will also setup a context and store it.

fw_next_firmware_bytes() will get passed more firmware bytes and
   tells us again how much it still need. It will get passed the
   context setup by fw_begin_firmware_store(). 
   
   This function can also abort a download by returning "no bytes
   needed anymore" and marking the firmware "invalid" in the
   context, which fw_end_firmware_store() will use to return
   "discard this firmware" to the firmware fs.

   Also this function is not really necessary, if we set the
   filesize of the firmware (truncate()) in firmware fs after
   fw_begin_firmware_store() and let the VFS do its magic.

fw_end_firmware_store() will be called, after user space closed
   the file descriptor (Note: This will handle SIGKILL also). It
   must decide, whether the downloaded firmware is valid and will
   be stored and can be used or will be discarded. It gets passed
   the context setup by fw_begin_firmware_store() and will free
   it's resources, if not needed anymore.

After fw_end_firmware_store(), the firmware can be downloaded to
the device (not before!).

This is much simpler, then it sounds. The only problems are:
   1.  getting the size of the firmware to be downloaded
      a) firmware has always the same size, so this is a constant
      b) firmware has size encoded -> use this 
      c) firmware size is file size -> need to wrap this to be like 1.b)

   2. decide, whether the firmware is valid
      a) checksum
      b) versions
      c) none -> trust or wrap to match 2.a) and/or 2.b)

What do you think?

Defining the prototypes and finding the places to hook into is
left as an exercise to the reader ;-)

The current idea (special file sytem) is great, but the interface
to the driver is not really perfect.

Regards

Ingo Oeser

  parent reply	other threads:[~2003-05-16 14:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 20:03 Manuel Estrada Sainz
2003-05-16  8:07 ` Oliver Neukum
2003-05-16  9:56   ` Manuel Estrada Sainz
2003-05-16 15:53     ` Oliver Neukum
2003-05-16 18:31       ` Manuel Estrada Sainz
2003-05-16 22:22         ` Oliver Neukum
2003-05-17  0:59           ` Manuel Estrada Sainz
2003-05-17  4:00             ` Robert White
2003-05-17 13:23           ` Alan Cox
2003-05-17 14:57             ` Manuel Estrada Sainz
2003-05-16 18:49       ` Jean Tourrilhes
2003-05-16 22:24         ` Oliver Neukum
2003-05-16 23:21         ` Greg KH
2003-05-16 16:09   ` Alan Cox
2003-05-16 22:13     ` Oliver Neukum
2003-05-17  4:50       ` David Gibson
2003-05-17  7:02         ` Oliver Neukum
2003-05-17  8:21           ` David Gibson
     [not found] ` <Pine.LNX.4.55.0305151623520.2885@marabou.research.att.com>
2003-05-16  9:27   ` Manuel Estrada Sainz
2003-05-16 22:39   ` Greg KH
2003-05-16 13:13 ` Ingo Oeser [this message]
2003-05-16 17:07   ` Manuel Estrada Sainz
2003-05-16 22:36 ` Greg KH
2003-05-16 23:37   ` Manuel Estrada Sainz
2003-05-16 23:59     ` Greg KH
2003-05-17  4:47       ` David Gibson
2003-05-17  8:54         ` Manuel Estrada Sainz
2003-05-16 23:55   ` Oliver Neukum
2003-05-17  0:03     ` Greg KH
2003-05-17  2:42       ` Robert White
2003-05-17  4:44       ` David Gibson
2003-05-17  8:46         ` Manuel Estrada Sainz
2003-05-17  9:07           ` David Gibson
2003-05-17  9:50             ` Manuel Estrada Sainz
2003-05-17 10:30             ` Manuel Estrada Sainz
2003-05-20  5:21               ` David Gibson
2003-05-20  8:07                 ` Manuel Estrada Sainz
2003-05-21  4:21                   ` Greg KH
2003-05-21  7:06                     ` Manuel Estrada Sainz
2003-05-17 10:51   ` Manuel Estrada Sainz
2003-05-17 13:21   ` Ingo Oeser
2003-05-17 15:15     ` Manuel Estrada Sainz

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=20030516151352.D626@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=Thomas.Downing@ipc.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=jt@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=proski@gnu.org \
    --cc=ranty@debian.org \
    --cc=simon@thekelleys.org.uk \
    /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

Powered by JetHome