On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > > kernel_read_file_from_path() can try to read a file from > > the system's filesystem. This is typically done for firmware > > for instance, which lives in /lib/firmware. One issue with > > this is that the kernel cannot know for sure when the real > > final /lib/firmare/ is ready, and even if you use initramfs > > drivers are currently initialized *first* prior to the initramfs > > kicking off. > > Why? do_initcalls() is called prior to prepare_namespace(), other than that we have no strict rules over where the real rootfs should be, and since we have pivot_root() its up to userspace to decide when/how the real rootfs goes. This and the fact that its also up to userspace to design what files to place in initramfs of further rootfs -- only userspace will know for sure when all firmware for all drivers is really ready. > > During init we run through all init calls first > > (do_initcalls()) and finally the initramfs is processed via > > prepare_namespace(): > > What's the downside of moving initramfs cpio extraction earlier in the boot? That would help users of initrafms, some folks seem to not want to use initramfs, one of such users are that of the large firmwares for remote-proc (Documentation/remoteproc.txt), we're talking about over 200 MiB for some firmware for example. > 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 but -- so long as the drivers that need firmware early are dumped into initramfs. We have no assurances/warnings for this, but we can add such things if we want them. This would not resolve the race for non-initramfs users / pivot_root() changes. 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
