Re: Why is the deferred initcall patch not mainline?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Oct 2014, Rob Landley wrote:

> On 10/23/14 14:05, Nicolas Pitre wrote:
> > On Thu, 23 Oct 2014, Alexandre Belloni wrote:
> > 
> >> On 23/10/2014 at 13:56:44 -0400, Nicolas Pitre wrote :
> >>> On Thu, 23 Oct 2014, Bird, Tim wrote:
> >>> Why a trigger?  I'm suggesting no trigger at all is needed.
> >>>
> >>> Let all initcalls start initializing whenever they can.  Simply that 
> >>> they shouldn't prevent user space from running early.
> >>>
> >>> Because initcalls are running in parallel, then they must be using 
> >>> separate kernel threads.  It may be possible to adjust their priority so 
> >>> if one of them is actually using a lot of CPU cycles then it will run 
> >>> only when all the other threads (including user space) are no longer 
> >>> running.
> >>>
> >>
> >> You probably can't do that without introducing race conditions. A number
> >> of userspace libraries and script are actually expecting init and probe
> >> to be synchronous.
> > 
> > They already have to cope with the fact that most things can be 
> > available through not-yet-loaded modules, or may never be there at all. 
> > If not then they should be fixed.
> > 
> > And if you do rely on such a feature for your small embedded 
> > system then you won't have that many libs and scripts to fix.
> 
> There are userspace libraries distinguishing between init and probe?
> I.E. treating them as two separate things already?

Why not?

> So how were they accessing them as two separate things before this patch
> set?

Before engaging a conversation with a device, you verify if it exists 
first?

> >> I will refer to the async probe discussion and the
> >> following thread:
> >>
> >> http://thread.gmane.org/gmane.linux.kernel/1781529
> > 
> > I still don't think that is a good idea at all.  This async probe 
> > concept requires a trigger from user space and that opens many cans of 
> > worms as user space now has to be aware of specific kernel driver 
> > modules, their ordering dependencies, etc.
> > 
> > My point is simply not to defer any initialization at all.  This way you 
> > don't have to select which module or initcall to send a trigger for 
> > later on.
> 
> Why would this be hard?
> 
> for i in $(find /sys/module -name initstate)
> do
>   [ "$(cat $i)" != live ] && echo "kick" > $i
> done

You should have a look at /sys/bus/*/*probe then.  Maybe it does what 
you need already.

> And I'm confused that you're concerned about init order so your solution
> is to do nothing, thereby preserving the existing init order which could
> not _possibly_ be exposed verbatim to userspace...

The kernel already has the deferred probe mechanism to cope with the 
init ordering which, as experience has shown, may only be dealt with at 
run time.  All attempts to create that ordering statically in the past 
have failed.  So what do you want exposed verbatim to user space again?

> > Once again, what is the actual problem you want to solve?  If it is 
> > about making sure user space can execute ASAP then _that_ should be the 
> > topic, not figuring out how to implement a particular solution.
> > 
> >> Anyway, your userspace will have to have a way to know what has been
> >> initialized.
> > 
> > Hotplug notifications via dbus.
> 
> Wait, we need a _third_ mechanism for hotplug notifications now? (The
> /proc/sys/kernel/hotplug helper, netlink, and you want another one?)

No, I actually meant hotplug and netlink.  My bad.

> >> On my side, I was also using that mechanism to delay the network stack 
> >> init but I still want to know when my dhcp client can start for 
> >> example.
> > 
> > Ditto.  And not only do you want to know when the network stack is 
> > initialized, but you also need to wait for a link to be established 
> > before DHCP can work.
> 
> Um, doesn't the existing hotplug mechanism _already_ give us
> notification that eth0 and similar showed up? (Pretty sure I hit that
> while poking at mdev, although it was a while ago...)

Indeed it does. So no new user space notification mechanisms are needed 
which is my point.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux