On Wed, Aug 03, 2016 at 12:42:14AM -0700, Dmitry Torokhov wrote: > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: > >> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: > >> >>>The sysdata API's main goal rather is to provide a flexible API first, > >> >>>compartamentalizing the usermode helper was secondary. But now it seems > >> >>>I may just also add devm support too to help simplify code further. > >> >> > >> >>I missed the point that you plan to add usermode helper support to > >> >>the sysdata API. > >> > > >> >I had no such plans, when I have asked folks so far about "hey are you > >> >really in need for it, OK what for? " and "what extended uses do you > >> >envision?" so I far I have not gotten any replies at all. So -- instead > >> >sysdata currently ignores it. > >> > >> So you argue for the remoteproc use case with 100+ MB firmware that > >> if there is a way to load after pivot_root() (or other additional > >> firmware partition shows up) then there is no need at all for > >> usermode helper? > > > > No, I'm saying I'd like to hear valid uses cases for the usermode helper and so > > far I have only found using coccinelle grammar 2 explicit users, that's it. My > > patch series (not yet merge) then annotates these as valid as I've verified > > through their documentation they have some quirky requirement. > > In certain configurations (embedded) people do not want to use > initramfs nor modules nor embed firmware into the kernel. In this case > usermode helper + firmware calss timeout handling provides necessary > wait for the root filesystem to be mounted. > > If we solve waiting for rootfs (or something else that may contain > firmware) then these cases will not need to use usermode helper. Given most distributions already disable FW_LOADER_USER_HELPER_FALLBACK and grammar shows we only have 2 explicit users of the usermode helper I'd prefer if we indeed could just compartamentalize the usermode helper and not rely on it further. Furthermore I think its possible address this issue, and suggested at least one idea how for now. With a bit further review I'm in hope we can address this well, not only for the firmware API but for all other kernel_read_file*() users. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
