On Thu, Oct 01, 2015 at 07:34:25PM -0700, Isaac Dunham wrote: > On Thu, Oct 01, 2015 at 04:42:34AM -0500, Rob Landley wrote: > > Still going through old posts, I'm up to: > > > > On 08/09/2015 12:24 AM, Isaac Dunham wrote: > > >>> > > If hard-coding "modprobe -bq $MODALIAS" int mdev is desireable, I > > >>> > > can send > > >>> > > that; but I suspect it's not quite fit for inclusion. > > >> > > > >> > I'd be interested in seeing the patch. > > > Attached! > > > > > > Thanks, > > > Isaac Dunham > > > > > >>From 0acde7ff07603e7b485bc19ec4a49b3010c49966 Mon Sep 17 00:00:00 2001 > > > From: Isaac Dunham <[email protected]> > > > Date: Mon, 3 Aug 2015 13:28:36 -0700 > > > Subject: [PATCH] mdev: autoload modules on hotplug. > > > > > > --- > > > toys/pending/mdev.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/toys/pending/mdev.c b/toys/pending/mdev.c > > > index a13a53d..b273d4a 100644 > > > --- a/toys/pending/mdev.c > > > +++ b/toys/pending/mdev.c > > > @@ -58,6 +58,8 @@ static void make_device(char *path) > > > } else { > > > // if (!path), do hotplug > > > > > > + if ((temp = getenv("MODALIAS"))) > > > + xexec((char *[]){"modprobe", temp, 0}); > > > if (!(temp = getenv("SUBSYSTEM"))) > > > return; > > > type = strcmp(temp, "block") ? S_IFCHR : S_IFBLK; > > > > The problem here is that does xexec, which is an exec so it replaces the > > current process, meaning the rest of processing doesn't happen. > > > > Do you mean xrun() maybe? (Spawns child process and waits for it to > > return, reporting exit code.) Or is modalias really the only thing this > > call is expected to do? > > (This was a preliminary patch that works for me but might not be > appropriate for upstream.) > > modprobe $MODALIAS is the only thing this is expected to do. > As far as I know (which is not very far), there are no cases where a single > uevent calls for loading a module and creating a device. > > I suppose that it's improper to rely on that without finding docs; > but it somehow seems wrong to do a fully blocking call to modprobe, and > serially with that check if we need to create a device. > > Maybe (1) try to fork(); (2) if we succeed, xexec() modprobe; (3) do the > whole mknod/chmod/... bit if appropriate; (4) on completion of that, > call wait(). > Note that a forkbomb, which could temporarily result in fork() failing, > should not make the hotplugger die if it's long-running. Making module > loading fail temporarily seems like it would be better.
This will not be nommu compatible. I think this is why Rob suggested xrun. > > (I note that I have a todo item to implement demon mode doing the > > netlink thing, in which case xexec() would again be the wrong thing...) > > Agreed. But then, wouldn't xrun() also be the wrong thing? Why? Rich _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
