On 03-08-16 09:42, Dmitry Torokhov wrote:

On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez [off-list ref] wrote:

quoted

On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:

quoted

On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:

quoted

On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:

quoted

quoted

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.

And there are people who don't have a usermode helper running at all in
their configuration, but I guess they should disable the helper.

In my opinion the kernel should provide functionality to user-space and
user-space providing functionality to the kernel should be avoided.

If we solve waiting for rootfs (or something else that may contain
firmware) then these cases will not need to use usermode helper.

If firmware (or whatever) API could get notification of mount syscall it
could be used to retry firmware loading instead of periodic polling.
That leaves the question raised by you about when to stop trying. The
initlevel stuff is probably a user-space only concept, right? So no
ideas how the kernel itself could decide except for a "long" timeout.

Regards,
Arend