On 10/27/2014 01:29 PM, Nicolas Pitre wrote:
On Fri, 24 Oct 2014, Geert Uytterhoeven wrote:
Several patches are linked from
http://elinux.org/Deferred_Initcalls
Latest version is
http://elinux.org/images/5/51/0001-Port-deferred-initcalls-to-3.10.patch
In the hope of providing some constructive and concrete feedback to this
thread, here's what I have to say about the patch linked above ( I
looked only at the latest version):
- Commented out code is not acceptable for mainline. But everyone knows
that already.
- Returning a null byte through the /proc file is dubious.
- The /proc interface is probably not the best. I'd go with an entry in
/sys/kernel instead.
- If the deferred_initcall section is empty, this could return 1 upfront
and do the free_initmem() earlier as it used to.
- It was mentioned somewhere that the config system could use a 4th
state in addition to n, m and y. That would be required before this
goes upstream simply to express all the dependencies between modules.
Right now if a core module is configured with m, then all the
submodules that depend on it inherit the modular-only restriction.
The same would need to be enforced for deferred initcalls.
- Currently all deferred initcalls are lumped together in a single
section with no regards to the original initcall level. This is likely
to cause trouble if two initcalls are called in a different order than
intended. Nothing prevents that from happening right now.
This patch is still not generic enough for mainline inclusion IMHO. It
currently falls in the you better know what you're doing category and
that is possibly good enough for its actual users. Trying to make this
more generic is going to require some more work. And this would have to
come with serious arguments explaining why simply using modules in the
first place is not acceptable.
Sorry to take so long to reply. This feedback is very welcome,
and I appreciate the time taken to review the patch. I
apologize in advance for the rather long response...
I have been thinking about the points you made previously,
and have given the problem space some more thought. I agree
that as it stands this is a very niche solution, and it would
be good to think about the broader picture and how things
might be designed differently to make the feature usable
more easily and to a broader group.
Taking a step back, the overall goal is to allow user space
to do stuff while the kernel is still initializing statically
linked drivers, so the device's primary function can be ready
as soon as possible (and not wait for secondarily-needed
functionality to initialize). For things that are able to be
made into a module (and for situations where the kernel module
loading is turned on), this feature should not be needed in
its current form. In that case, user space already has control
over module load ordering and timing.
The way the feature is expressed in the current code is that a
set of drivers are marked for deferred initialization (I'll refer
to this as issue 0). Then, at boot: 1) most drivers are initialized
normally, 2) user space is started, and then 3) user space indicates
to the kernel that the deferred drivers should be initialized.
This is very coarse, allowing only two categories of drivers: (ignoring
other boot phases for the moment) - regular drivers and deferred drivers.
It also requires source code changes to mark the drivers to be deferred.
Finally, it requires an explicit notification from user-space to complete
the process. All of these attributes are undesirable.
There may also be an opportunity here to work out more granular driver
load ordering, which would benefit other systems (especially those that
are hitting the EPROBE_DEFER issue).
As it stands now, the ordering of the initcalls within a particular level
is pretty much arbitrary (determined by link order, usually without oversight
by the developer). Just FYI, here are some numbers culled from a recent
kernel:
initcall macro number of instances in kernel source
--
early_init 446
core_init 614
postcore_init 150
arch_init 751
subsys_init 573
fs_init 1372
device_init 1211
late_init 440
I'm going to rattle off a few ideas - I'm not sure which ones might
stick, I just want to bounce these around and see what people think.
Note that I didn't think of most of these, but I'm just repeating ones
that have been stated, and adding a few thoughts of my own.
First, if the ordering of initialization is not the default
provided by the kernel, it needs to be recorded somewhere. A developer
needs to express it (or a tool needs to figure it out), but if it is
going to be reflected in the final kernel behaviour (or image), the
kernel needs it at boot time (if not compile
