From: "Michael Chan" <mchan@broadcom.com>
To: "Rick Jones" <rick.jones2@hp.com>
Cc: "Bastian Blank" <waldi@debian.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] bnx2: Use request_firmware()
Date: Mon, 23 Mar 2009 18:44:38 -0700 [thread overview]
Message-ID: <1237859078.18617.59.camel@HP1> (raw)
In-Reply-To: <49C836D0.1080304@hp.com>
On Mon, 2009-03-23 at 18:26 -0700, Rick Jones wrote:
> Michael Chan wrote:
> > On Mon, 2009-03-23 at 17:14 -0700, Rick Jones wrote:
> >
> >>Michael Chan wrote:
> >>
> >>>May be I'll break up each firmware section into a
> >>>different file and the file name will be updated with each version.
> >>>This will allow different sections to be updated separately and older
> >>>kernels will still have access to the older firmware.
> >>
> >>Is that really necessary? It is enough "fun" finding just the one firmware file
> >>as it is.
> >
> >
> > If all the firmware sections are in the same file, much of the firmware
> > file will be duplicated in a new file when we update just one section.
>
> So? Perhaps I'm just experiencing distro pain which may not continue to exist or
> which may not matter to netdev, but when one is installing to a system that uses
> a core NIC which has firmware cast-out into "non-free" siberia, life is "fun"
> enough making sure one has the one firmware file let alone N of them. If I now
> have to make sure I have all N firmware files, and they are to be updated
> separately, either that means I have to find N packages, or the distros are going
> to package them into one "uber" package that might as well be a single firmware
> file anyway.
>
I think we can assume that distros will package firmware files (make
firmware_install) properly and not require users to install these
firmware files on their own.
next prev parent reply other threads:[~2009-03-24 1:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 22:29 [PATCH] bnx2: Use request_firmware() Ben Hutchings
2009-03-19 23:04 ` Michael Chan
2009-03-19 23:25 ` Bastian Blank
2009-03-20 22:50 ` David Miller
2009-03-23 21:47 ` Michael Chan
2009-03-23 22:02 ` David Miller
2009-03-23 22:29 ` Bastian Blank
2009-03-23 23:24 ` Michael Chan
2009-03-24 0:14 ` Rick Jones
2009-03-24 1:11 ` Michael Chan
2009-03-24 1:26 ` Rick Jones
2009-03-24 1:44 ` Michael Chan [this message]
2009-03-24 4:27 ` Ben Hutchings
2009-03-24 7:42 ` Bastian Blank
2009-03-24 15:27 ` Michael Chan
2009-03-23 22:32 ` Bastian Blank
2009-03-23 23:28 ` Michael Chan
2009-04-01 18:01 ` Michael Chan
2009-04-02 8:05 ` David Miller
[not found] <1238778120-8132-1-git-send-email-mchan@broadcom.com>
2009-04-04 23:51 ` David Miller
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=1237859078.18617.59.camel@HP1 \
--to=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
--cc=waldi@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