From: Marcel Holtmann <marcel@holtmann.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
"Luis R. Rodriguez" <mcgrof@gmail.com>,
linux-kernel@vger.kernel.org,
linux-wireless <linux-wireless@vger.kernel.org>,
Vipin Mehta <Vipin.Mehta@atheros.com>
Subject: Re: Firmware versioning best practices II
Date: Sun, 21 Feb 2010 11:13:42 +0100 [thread overview]
Message-ID: <1266747222.18491.5.camel@violet> (raw)
In-Reply-To: <1266665535.1820.4238.camel@macbook.infradead.org>
Hi David,
> > > > That doesn't make much sense anyway. If the firmware filename is
> > > > foo-$APIVER-$CODEVER every code change would need a corresponding
> > > driver
> > > > change. If it is just foo-$APIVER then the $CODEVER can be embedded
> > > in
> > > > the firmware file and printed so you know which code you're using,
> > > but
> > > > if it doesn't influence the API I don't see why it should be part of
> > > the
> > > > filename?
> > >
> > > The idea is that just like with shared libraries, you have a symlink
> > > from the 'soname' foo-3.fw to the actual file foo-3-1.4.1.fw.
> >
> > Ah ok. I indeed do that manually with iwlwifi firmware :)
> >
> > > For shared libraries, it's easy to create those symlinks automatically
> > > using ldconfig. For firmware that doesn't really work though -- since
> > > the soname isn't encoded in the file like it is in ELF libraries.
> >
> > Right. Though I guess we could come up with a unified firmware wrapper
> > format that the firmware loader can unwrap.
>
> I suppose we could, but this seems like overkill to me.
I have to agree. This looks like total overkill to me.
Just use the $APIVER in the firmware filename. And if someone wants to
keep track of more details then they can manually symlink them.
Unless we have full control over the source code of every firmware used
in the kernel, why bother. It is up to the companies providing them
anyway to make sure everything works as expected and the community can't
fix it.
Regards
Marcel
next prev parent reply other threads:[~2010-02-21 10:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-20 2:23 Firmware versioning best practices II Luis R. Rodriguez
2010-02-20 10:35 ` David Woodhouse
2010-02-20 11:00 ` Johannes Berg
2010-02-20 11:09 ` David Woodhouse
2010-02-20 11:10 ` Johannes Berg
2010-02-20 11:32 ` David Woodhouse
2010-02-21 10:13 ` Marcel Holtmann [this message]
2010-02-22 19:14 ` Luis R. Rodriguez
2010-02-22 19:27 ` Marcel Holtmann
2010-02-22 21:03 ` Luis R. Rodriguez
2010-02-23 7:06 ` Marcel Holtmann
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=1266747222.18491.5.camel@violet \
--to=marcel@holtmann.org \
--cc=Vipin.Mehta@atheros.com \
--cc=dwmw2@infradead.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
/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).