DragonFly BSD
DragonFly kernel List (threaded) for 2010-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: firmware discussion

From: Joe Talbott <josepht@xxxxxxxxxx>
Date: Thu, 29 Apr 2010 11:08:35 -0400
Mail-followup-to: Aggelos Economopoulos <aoiko@cc.ece.ntua.gr>, kernel@crater.dragonflybsd.org

On Thu, Apr 29, 2010 at 01:12:05PM +0300, Aggelos Economopoulos wrote:
> Joe Talbott wrote:
> > On Thu, Mar 04, 2010 at 08:46:47AM +0100, Sascha Wildner wrote:
> >> Am 03.03.2010 18:11, schrieb Joe Talbott:
> >>> My personal feeling is that we should do whatever
> >>> we can to make porting drivers as easy as possible.
> >> Port from where? We've not only ported drivers from FreeBSD in the past.
> > 
> > My initial thought was to include both APIs though this would likely
> > lead to confusion.
> So, I was discussing the situation with firmware we can't redistribute
> legally. Getting the user to download it in, say, /etc/firmware would be
> easy enough, but apparently the freebsd firmware interface we've
> recently adopted to make the wireless sync easier assumes the firmware
> is contained in a module.
> This seems suboptimal to say the least. We don't want to have to build a
> module on the spot for each arbitrary file. One solution would be to
> have the kernel look into /etc/firmware at firmware_get() time
> (including some hack about the version number). Another would be to
> convert everything to use our old interface (straightforward, but some
> work). Yet another would be to let users of devices that require
> firmware that we can't distribute know that we're sorry for their plight
> but they're on their own.
> Which do we want to go with? Any other ideas?

Perhaps we can rework our old firmware API to be a drop-in replacement
for the FreeBSD one.  This would ease driver porting yet allow us to
use our /etc/firmware infrastructure.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]