Date: Thu, 29 Aug 2019 08:45:32 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: "Conrad E. Meyer" <cem@freebsd.org>, Yuri Pankov <yuripv@yuripv.net>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: ichsmb(4) and msleep() Message-ID: <CANCZdfrVFPvY_8hwcGydXiPh4E7ZDmru2VHZaWH8ENerxtYTTA@mail.gmail.com> In-Reply-To: <be1690d4f1d1a784030711169b6fd416b2dd5c5c.camel@freebsd.org> References: <7dfebbd3-85d6-c7b7-b83b-fae8b644649e@yuripv.net> <478965aa-5256-e356-5339-de6fb82c3459@selasky.org> <63daa36a-5c22-6b08-3cd7-562fa961ab61@yuripv.net> <7f6de96d-8b56-e242-8950-04a20b197bce@selasky.org> <311a21e3-ed61-8679-b416-b2a4c255c6e7@yuripv.net> <1f91f7a6-050d-d690-d374-6b06950d2ce2@yuripv.net> <CANCZdfpevZ2PyLa9yai6cA5JYgNybgyHp0=1=er%2BeuJGcu9hew@mail.gmail.com> <4201916c-0f7f-0bf6-2d17-e9f6a1879ba7@yuripv.net> <CAG6CVpW1kYqg7NgK5WfOFRBcsb0WbM1G8A5PPfeTDpsZ8Cxw3A@mail.gmail.com> <be1690d4f1d1a784030711169b6fd416b2dd5c5c.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 29, 2019 at 8:29 AM Ian Lepore <ian@freebsd.org> wrote: > On Wed, 2019-08-28 at 20:27 -0700, Conrad Meyer wrote: > > On Wed, Aug 28, 2019 at 6:35 AM Yuri Pankov <yuripv@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. > Yes. In fact, I think this idiom is so wide spread, we'd be better off doing 'return (bus_delayed_attach_children(dev));' at the end to signal this and gather together all current uses in the tree under that. Generally, if you need interrupts enabled and scheduling running to configure your children, you should do that anyway. It's a convenient late point, and it's better to do all the late things at the same time with the same idiom than to try to hyper-optimize when they get done. We've cleaned up a number of messes where driver writers invent their own thing due to ignorance of the proper thing (or because there wasn't a recognition that it was similar to what lots of other drivers did). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrVFPvY_8hwcGydXiPh4E7ZDmru2VHZaWH8ENerxtYTTA>