From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mtd <linux-mtd@lists.infradead.org>,
sf-linux-drivers <linux-net-drivers@solarflare.com>,
flashrom <flashrom@flashrom.org>
Subject: Re: [RFC] Online firmware upgrade in non-embedded systems
Date: Wed, 29 Sep 2010 15:43:58 +0200 [thread overview]
Message-ID: <4CA3429E.4070104@gmx.net> (raw)
In-Reply-To: <1285765850.2283.15.camel@achroite.uk.solarflarecom.com>
On 29.09.2010 15:10, Ben Hutchings wrote:
> On Wed, 2010-09-29 at 14:45 +0200, Carl-Daniel Hailfinger wrote:
>
>> On 29.09.2010 14:35, Ben Hutchings wrote:
>>
>>> On Wed, 2010-09-29 at 00:41 +0200, Carl-Daniel Hailfinger wrote:
>>>
>>>
>>>> [adding flashrom@flashrom.org to CC, senders will be whitelisted after a
>>>> short delay]
>>>>
>>>> On 28.09.2010 19:59, Ben Hutchings wrote:
>>>>
>>>>
>>>>> Network and disk controllers normally have at least some firmware in
>>>>> flash to support their use as boot devices. [...]
>>>>>
>>>>>
>>>>>
>>>> Given that the flashrom utility <http://www.flashrom.org/> (GPLv2)
>>>> supports flashing many network cards, SATA/PATA controllers, graphics
>>>> cards, and of course the main system firmware/BIOS/EFI, and it does that
>>>> from userspace without any kernel support,
>>>>
>>>>
>>> [...]
>>>
>>> I'm looking for a clean solution, not a hack.
>>>
>>>
>> What would qualify as a clean solution?
>>
>
> One where hardware access is mediated by the kernel, and doesn't involve
> unloading or potentially conflicting with the driver for that hardware.
>
flashrom can ask the kernel driver to "please stop accessing flash". No
unloading needed, no conflict in place.
>> And is cross-platform code one of your goals?
>>
>
> Not at this level. At the application level, yes, but we already have a
> working application so I'm not interested in using flashrom for that.
>
I see. Just because I'm interested in how other flashing applications
solve this: Does that application work on *BSD as well? And could you
tell me the name of the app so I can take a look at it? Thanks.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
next prev parent reply other threads:[~2010-09-29 13:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 17:59 [RFC] Online firmware upgrade in non-embedded systems Ben Hutchings
2010-09-28 18:45 ` Alexander Clouter
2010-09-28 22:41 ` Carl-Daniel Hailfinger
2010-09-29 12:35 ` Ben Hutchings
2010-09-29 12:45 ` Carl-Daniel Hailfinger
2010-09-29 13:10 ` Ben Hutchings
2010-09-29 13:43 ` Carl-Daniel Hailfinger [this message]
2010-09-29 12:34 ` Artem Bityutskiy
2010-09-29 12:44 ` Ben Hutchings
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=4CA3429E.4070104@gmx.net \
--to=c-d.hailfinger.devel.2006@gmx.net \
--cc=bhutchings@solarflare.com \
--cc=flashrom@flashrom.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).