From: Manuel Estrada Sainz <ranty@debian.org>
To: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
Cc: Greg KH <greg@kroah.com>, 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>,
jt@hpl.hp.com, Pavel Roskin <proski@gnu.org>
Subject: Re: request_firmware() hotplug interface, third round.
Date: Sat, 17 May 2003 17:15:30 +0200 [thread overview]
Message-ID: <20030517151530.GB10314@ranty.ddts.net> (raw)
In-Reply-To: <20030517152129.F626@nightmaster.csn.tu-chemnitz.de>
On Sat, May 17, 2003 at 03:21:29PM +0200, Ingo Oeser wrote:
> On Fri, May 16, 2003 at 03:36:24PM -0700, Greg KH wrote:
> > Other than those very minor tweaks, I like this interface, it's looking
> > very good. I wouldn't worry about any "checksum" calcuation crud, it's
> > up to the userspace tool dumping the firmware to the kernel to make sure
>
> Ok, if that is true, then we could also have this tool enforce a
> size. Otherwise we are reading and reading without ever ending
> and allocating a lot of kernel resources while we are at it.
A privileged script will be able to kill the system anyway it wants, I
don't think that this is needed.
However, forcing an standard header on firmware images including the
size would allow size checks without the need for an specialized tool.
Or to prevent memory reallocation every PAGE_SIZE bytes, a tentative
size could be written to 'loading' so its meaning would become:
loading > 1:
Start/restart a load of the specified size.
loading = 1:
Start/restart a load of unknown size.
loading = 0:
Finish load.
loading = -1:
Cancel load.
> If we know the size, then we also now start and end. So the
> "loading" attribute can certainly go.
I personally like to have explicit start/end, which also allows
cancellation and restart of the firmware load.
Regards
Manuel
--
--- Manuel Estrada Sainz <ranty@debian.org>
<ranty@bigfoot.com>
<ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
next prev parent reply other threads:[~2003-05-17 15:02 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
2003-05-16 13:13 ` Ingo Oeser
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 [this message]
[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
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=20030517151530.GB10314@ranty.ddts.net \
--to=ranty@debian.org \
--cc=Thomas.Downing@ipc.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=jt@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=proski@gnu.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
all inboxes | Powered by JetHome®