On Tue, Oct 4, 2016 at 5:12 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: >> >> I am not sure how/why a firmware loading daemon would be a better >> idea now. What Marc describes that Josh proposed with signals for >> userspcae seems more aligned with what we likely need > > Quite frankly, I doubt you want a signal. > > You will want to have some way to specify where the firmware files > are. Right now we have "fw_path[]" which is hardcoded except for the > first entry that can be set as a module parameter. But you'd probably > want to expand on that, which implies some /sys or /proc interface. > > And once you do that, wouldn't it make more sense to just make the > "update the firmware path /proc/sys/kernel/fw_path file" make things > re-search for firmware? We can, but re-searching for firmware assumes we cache pending firmware, we currently don't, we just either process sync or async firmware requests. > In other words, the interface has to be something *sensible*. Not some > idiotic ad-hoc "send a signal" (of which that stupid original patch > was just a very odd example). Note that the races are beyond firmware, so all kernel_read_file_from_path() users, as such re-using such old /sys/ interafeces for firmware will not suffice to cover all ground now for the same race for other possible users. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
