Hi Sebastian, > > > Anyway, the drivers and the firmware are distributed together. A common > > > use case for many of our developers and some of our users is to check > > > out the source code, maybe hack on it some, build it, and run it out of > > > the sandbox (without installing). The problem is that udev can't find > > > the firmwares in peoples home directories. > > > > > > My proposal is to have the driver accept a modparam giving the absolute > > > path to the firmware file the user wants, and have the firmware.sh > > > helper read it from there, bypassing the normal firmware search path. > > > > use symlinks like everybody else. > > That's an option, true. However, it gets really inconvenient when you > have, for example, a stable version installed from the official package > and an experimental version in a sandbox in your home. > > Developing kernel drivers is super convenient in Linux because you can > give insmod absolute paths to load a specific file out of your development > directory, or you can let modprobe auto-fetch the installed driver module > from the standard path. > > 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. 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. Regards Marcel -- 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
