On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > >> I did some shuffling around of those code to make initmpfs work, does > >> anybody know why initramfs extraction _before_ we initialize drivers > >> would be a bad thing? > > > > No, but it seems sensible to me, if its done before do_initcalls() > > that should resolve the race for initramfs users > > initramfs should already be set up before drivers are. Actually you are right, the issue would only be for old initrd, for initramfs we populate that via rootfs_initcall(populate_rootfs), so as long as drivers in question use an init level beyond rootfs's we're good there. > Exactly what is it that has trouble right now? It would seem then that the only current stated race possible should then be non-initramfs users. One example if very large firmware for remote-proc, whereby an initramfs is just not practical or desirable. > The gating issue for initramfs is that technically the filesystem > setup needs to be done, which means that it currently ends up being > populated _fairly_ late in the initcall series, but certainly before > drivers. But since initramfs really only needs very limited filesystem > functionality, I assume Rob had few problems with just moving it > earlier. > > Still, what kind of ordering issues did people have? What is it that > needs to load files even before driver init? Some crazy subsystem? No, I think this is just about non-initramfs users now, if we disregard old initrd users. Bjorn, Marc, correct me if I'm wrong, as I think its so far you both who have seemed to run into race issues and have then ended up trying to look for hacks to address this race or considered using the usermode helper (which we're trying to minimize users for). Daniel seems to note a lot of video drivers use firmware on probe as well so there's a potential issue for those users if they don't use initramfs. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
