Messages in this thread | | | Date | Sun, 31 Aug 2014 19:03:06 -0400 | From | Tejun Heo <> | Subject | Re: [RFC v1 0/3] driver-core: add asynch module loading support |
| |
Hello, Dmitry.
On Sun, Aug 31, 2014 at 03:51:40PM -0700, Dmitry Torokhov wrote: > > > Luis, care to redo the patches in this way? It should be a lot simpler > > > (no messing around with init levels and linker fun...) > > > > I don't think binding that switch to the driver is gonna work. This > > is mainly about the behavior expected by the entity which initiated > > module loading not about specific drivers. > > Why would you say that? In my particular userspace we do not have modules.
Heh, I think we're just thinking about different problems. For me, this is all from the bug report that I was cc'd on where systemd times out module load after 30s and sends SIG_KILL to the module loading thread which aborts module loading which in turn leads to nasty things. The logical way to address that is separating out module loading and device probing. Given the way we associate drivers with devices these days, it makes a lot of sense to separate them out anyway.
> > I'm fairly certain that > > there are userland scripts which depend on synchronous device probing > > on module loading, especially for storage devices, so we can't simply > > mark, say, libata as needing async probing and do it always > > asynchronously. > > Right. But for many devices (input ones for example, USB as well, etc) that are > essentially hot-pluggable userspace has been long ready to handle async order.
Sure, all modern userspace should be completely fine without ordering but there are niche userspaces out in the wild which don't do much of the dynamic things and just expect devices to be assigned consistent nodes across multiple boots, so keeping the order is mostly about backward compatibility.
Thanks.
-- tejun
| |