Hi Sebastian, > > > > 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. > > > > using your own firmware.sh and an udev rule is so simply. So don't > > bother the kernel with any changes. Also the kernel does not make policy > > decisions. The /lib/firmware location is a userspace policy. > > Did you read my email? > > You're the only one here talking about putting policy in the kernel, > or making any kernel changes at all. > > I'm suggesting a small change to the existing policy in *udev*. This is > the list for discussing udev, no? you are talking about adding a module parameter for a absolute path to the driver. That is putting policy into the kernel. And again, what is the big issue with an udev rule for your development case? 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
