Initialization ordering problem

Initialization ordering problem

[William Jhun]

Hello,

Since mtd chip drivers (cfi_probe.c, etc) register their presence during
module (or __initcall) initialization, an attempt to probe for flash
devices before all mtd components have initialized may fail. Our
platform-specific code (which in turn calls do_map_probe() in chipreg.c)
just happens to get linked in before the mtd code. Resultingly, all
probes fail as the required chip drivers are not present. Is there a
better solution for this than changing the link order? Had the chip
drivers been available as modules and CONFIG_KMOD set, they would have
been loaded and initialized on-demand. However, when linking everything
statically, this fails miserably. I could work up some kludge to make
our platform-specific flash initialization code link in after the mtd
code, but this would be ugly.

Any ideas?

Thanks,
Will

Re: Initialization ordering problem

[Jonas Holmberg]

On Tue, 2002-03-19 at 07:14, William Jhun wrote:
> I could work up some kludge to make
> our platform-specific flash initialization code link in after the mtd
> code, but this would be ugly.

Why don't you want to change the link order? Isn't it logical to link in
the architecture independent parts before the architecture speficic ones
so that the arch specific code can use the frameworks in the arch
independent code?

/Jonas

Re: Initialization ordering problem

[William Jhun]

On Tue, Mar 19, 2002 at 07:50:12AM +0100, Jonas Holmberg wrote:
> On Tue, 2002-03-19 at 07:14, William Jhun wrote:
> > I could work up some kludge to make
> > our platform-specific flash initialization code link in after the mtd
> > code, but this would be ugly.
> 
> Why don't you want to change the link order? Isn't it logical to link in
> the architecture independent parts before the architecture speficic ones
> so that the arch specific code can use the frameworks in the arch
> independent code?

Hm, this isn't immediately logical to me. I would think that the
platform-dependent setup would have to take place to set up any
subsystems that may be used by the different drivers. I'm not clear on
this one.

This would require linking "$(CORE_FILES)" last in the vmlinux link
order (top-level Makefile):

***************
*** 261,268 ****
  vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
  	$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
  		--start-group \
- 		$(CORE_FILES) \
  		$(DRIVERS) \
  		$(NETWORKS) \
  		$(LIBS) \
  		--end-group \
--- 261,268 ----
  vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
  	$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
  		--start-group \
  		$(DRIVERS) \
+ 		$(CORE_FILES) \
  		$(NETWORKS) \
  		$(LIBS) \
  		--end-group \

I may try this temporarily, but is this the "correct" way to deal with
the problem? I'm not sure it would even work.

What I don't understand is why the MTD code depends on separate
__initcall functions to execute for complete initialization - isn't it
possible to create, if the MTD code is being linked directly in the
kernel, a static array of subsystems that need to be initialized or a
list of callbacks? A brief glance shows that the Linux IDE code attempts
to do something similar (drivers/ide/ide.c, ide_init_builtin_drivers()):

        /*
         * Attempt to match drivers for the available drives
         */
#ifdef CONFIG_BLK_DEV_IDEDISK
        (void) idedisk_init();
#endif /* CONFIG_BLK_DEV_IDEDISK */
#ifdef CONFIG_BLK_DEV_IDECD
        (void) ide_cdrom_init();
#endif /* CONFIG_BLK_DEV_IDECD */
#ifdef CONFIG_BLK_DEV_IDETAPE
        (void) idetape_init();
#endif /* CONFIG_BLK_DEV_IDETAPE */
#ifdef CONFIG_BLK_DEV_IDEFLOPPY
        (void) idefloppy_init();
#endif /* CONFIG_BLK_DEV_IDEFLOPPY */
#ifdef CONFIG_BLK_DEV_IDESCSI
 #ifdef CONFIG_SCSI
        (void) idescsi_init();
 #else
    #warning ide scsi-emulation selected but no SCSI-subsystem in kernel
 #endif
#endif /* CONFIG_BLK_DEV_IDESCSI */

Would something like this be warranted? It sounds like 2.5.x offers some
neat features, but we're not there yet - we're stuck with 2.4.x kernels
at the moment.

Thanks,
Will

Re: Initialization ordering problem

[Jonas Holmberg]

On Tue, 2002-03-19 at 20:11, William Jhun wrote:
> I may try this temporarily, but is this the "correct" way to deal with
> the problem? I'm not sure it would even work.

I don't know what it looks like in your arch-specific Makefile. But I
changed ours like this: 

@@ -55,7 +55,8 @@
 # each others config options
 SUBDIRS += arch/cris/boot/rescue
 endif
-CORE_FILES += arch/cris/kernel/kernel.o arch/cris/mm/mm.o
arch/cris/drivers/drivers.o
+CORE_FILES += arch/cris/kernel/kernel.o arch/cris/mm/mm.o
+DRIVERS += arch/cris/drivers/drivers.o
 LIBGCC = $(shell $(CC) $(CFLAGS) -print-file-name=libgcc.a)
 LIBS := $(TOPDIR)/arch/cris/lib/lib.a $(LIBS)
$(TOPDIR)/arch/cris/lib/lib.a $(LIBGCC)

Best regards
/Jonas

Re: Initialization ordering problem

[David Woodhouse]

On Mon, 18 Mar 2002, William Jhun wrote:

> Hello,
> 
> Since mtd chip drivers (cfi_probe.c, etc) register their presence during
> module (or __initcall) initialization, an attempt to probe for flash
> devices before all mtd components have initialized may fail. Our
> platform-specific code (which in turn calls do_map_probe() in chipreg.c)
> just happens to get linked in before the mtd code. Resultingly, all
> probes fail as the required chip drivers are not present. Is there a
> better solution for this than changing the link order? 

Ask Keith. I objected strongly at the time to the inter_module_xxx stuff
introducing these link order constraints where previously there were none.

In 2.5, you could possibly use subsys_initcall for the chip registrations 
to ensure they happen first.

-- 
dwmw2