From: Ben Hutchings <bhutchings@solarflare.com>
To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
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 14:10:50 +0100 [thread overview]
Message-ID: <1285765850.2283.15.camel@achroite.uk.solarflarecom.com> (raw)
In-Reply-To: <4CA334FA.2080707@gmx.net>
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.
> 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.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2010-09-29 13:10 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 [this message]
2010-09-29 13:43 ` Carl-Daniel Hailfinger
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=1285765850.2283.15.camel@achroite.uk.solarflarecom.com \
--to=bhutchings@solarflare.com \
--cc=c-d.hailfinger.devel.2006@gmx.net \
--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).