lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1266747222.18491.5.camel@violet>
Date:	Sun, 21 Feb 2010 11:13:42 +0100
From:	Marcel Holtmann <marcel@...tmann.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Johannes Berg <johannes@...solutions.net>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	linux-kernel@...r.kernel.org,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Vipin Mehta <Vipin.Mehta@...eros.com>
Subject: Re: Firmware versioning best practices II

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ