linux-kernel - Re: [PATCH][RFC] request_firmware examples and MODULE

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: <1157560971.5265.94.camel@perihelion>
Date:	Wed, 06 Sep 2006 17:42:51 +0100
From:	Jon Masters <jonathan@...masters.org>
To:	Victor Hugo <victor@...go.net>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	linux-kernel@...r.kernel.org,
	Victor Castro <victorhugo83@...oo.com>
Subject: Re: [PATCH][RFC] request_firmware examples and MODULE_FIRMWARE

On Tue, 2006-09-05 at 11:26 -0700, Victor Hugo wrote:

> On Sep 5, 2006, at 12:33 AM, Marcel Holtmann wrote:
> >
> > actually it has never been really a filename. It was a simple pattern
> > that the initial hotplug script and later the udev script mapped  
> > 1:1 to a filename on your filesystem. If you check the mailing list  
> > archives of LKML and linux-hotplug you will see that I always resisted
> > in allowing drivers to include a directory path in that call. A couple
> > of people tried this and it is not what it was meant to be.

That's fine. I agree with the idea - *but* it strikes me that we don't
really have a co-ordinated database of what module "patterns" map to
what on-disk firmware, aside from hotplug/udev scripts. We need to
co-ordinate this stuff a lot more. Or am I missing something? I'm happy
to setup a database on the kerneltools.org wiki if that's useful...

[ I've got a plan to extend some of the stuff I've been looking at in
the Fedora space - and some of you won't like me for it :P Basically I
want to put a GUI in front of DKMS/kmods/other module packaging/firmware
update utilities and automatically locate/build/install third-party GPL
(but not yet upstream) drivers on non-moving target distros. Evil stuff
like that also would find knowing about external firmware useful. ]

> Or like Jon Masters suggested have specific version numbers in the  
> pattern and have them map to specific versions in /lib/firmware and  
> make them all visible through MODULE_FIRMWARE.  I believe the  
> reasoning behind this was to make packaging drivers easier.

The reasoning behind MODULE_FIRMWARE is because firmware names can be
dynamically generated in the module so we can't know what it's going to
need ahead of time. I'd like to hook this up with the PCI ID/etc. of the
hardware that needs that firmware - so we really only package the
mimimum, but I think that's overkill.

> I believe that we should have a generic mapping in the driver (i.e,  
> "firmware.bin") and let the admin or the userspace hotplug scripts  
> take care of filename policy with a link to the correct firmware  
> version.
> 
> example :
> 
> firmware.bin -> firmware-xyz.bin
> 
> The main reason for not including speciic mapping in the driver is  
> that everytime a new firmware version is released the driver has to  
> be updated and recompiled.  Its much easier to change a hotplug script.

I'm trying to avoid the need to have lots of different places in
userland needing to track firmware versioning. But on some level, I just
need to know that a given driver is going to ask for 1 firmware with the
ID of "foo" - and a way to extrapolate where it is on disk to package.

Jon.

-
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/