ichsmb(4) and msleep()

[Ian Lepore]

On Wed, 2019-08-28 at 20:27 -0700, Conrad Meyer wrote:
> On Wed, Aug 28, 2019 at 6:35 AM Yuri Pankov <yuripv at yuripv.net> wrote:
> > 
> > Warner Losh wrote:
> > > What's the advantages of doing this instead of deferring attach until the
> > > interrupts are running?
> > 
> > None that I can think of, just going with what was suggested and seeing
> > other drivers doing the same.  Could you please name a driver that
> > defers attach until !cold?
> 
> I think pretty much all drivers attach when interrupts are enabled
> (not the same as !cold)?  At least x86 enables interrupts on BSP at
> SI_SUB_INTR, and DRIVER_MODULE drivers *load* at SI_SUB_DRIVERS, and
> the INTR one is ordered before the other.  My skim read is that
> drivers do not actually attach until SI_SUB_CONFIGURE.
> 
> I think the panic / test in sleepq_set_timeout_sbt is maybe overly
> strong?  !cold indicates the entire autoconfigure process has
> concluded.  But interrupts are available long before that.  Seems like
> hardclock is started at ~SI_SUB_CLOCKS?  Which is admittedly after
> DRIVERS, but still long before !cold.  I'm not sure what set of
> interrupt/timer functionality is needed for sleepq, but likely that
> condition can be relaxed.
> 
> If it cannot be relaxed enough for your driver, you could expand your
> DRIVER_MODULE() into the expanded macro, replacing SI_SUB_DRIVERS with
> a later stage.
> 
> 

Afaik, only x86 enables interrupts before SI_SUB_CONFIGURE.  Maybe
sparc64 does too.  Other arches do it as the last thing in
SI_SUB_CONFIGURE, usually in a function named configure_final() in
<arch>/autoconf.c.

-- Ian