On Thu July 3 2008 22:50:57 Marcel Holtmann wrote:
> > It'd be great if the kernel's budding firmware support had a similar
> > flexibility, for firmware developers and others. Allowing absolute
> > paths in request_firmware()/firmware.sh seems like a nice clean way to
> > provide this.
> >
> > Is there a technical reason this is a bad idea, or is it a subjective
> > "bad smell" type of thing? Because I dont smell it.
>
> the kernel doesn't make any policy decision on where the firmware files
> are stored. So this information doesn't belong there. A driver
> requesting and absolute path is a driver with a bug.
I agree that's a bug in the normal, everything-is-installed case.
I'm looking for a solution for a different use case, which is not well
supported out of the box. My use case is a firmware developer who wants
to test out different firmwares they're hacking on in their sandboxes.
The cleanest solution I can think of for this is to add a modparam
string firmware_name to the driver, and let the developer pass in the
absolute path of the firmware they want the driver to request this time.
All this would need is a tiny change in the userspace helper script.
In the "everything-is-installed" case the firmware_name modparam is not
specified; the driver requests its default firmware (by relative path),
and firmware.sh fetches it out of the normal system firmware directories
just like now.
Do all the other firmware developers out there symlink their sandboxes
into /lib/firmware? And update the symlink when they switch to a
different sandbox? And remove it when they finally install the firmware?
To me that seems messier than the proposed alternative.
How is this suggestion worse than insmod allowing you to load drivers
from your home? It seems like the same kind of thing, just for firmware.
> Also since you are talking about development here. So what has this to
> do with the upstream kernel and why do we need it there. You can always
> install your own firmware.sh file that does special things in case files
> are requested for your driver. And actually you don't even have to
> overwrite firmware.sh for it. Simply install a new udev rule for only
> that driver.
Yeah, our own udev rule and our own firmware.sh is one of the options
we're considering. It'd be easy to do. I just think it's a generally
good idea and I thought that upstream udev might be interested.
--
Sebastian Kuzminsky
you are the only light there is for yourself my friend
-- Gogol Bordello
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
