Michael Schnell <[EMAIL PROTECTED]> wrote: > > The main problem is that the region that you want to map for execution > > *must* be contiguous.
> That is obvious. Yep. Just making it explicit as it is the problem from which everything else has to flow. > > ramfs doesn't currently guarantee that unless you truncate the file before > > filling it, > > Of course not. Does the XIP aware executable "loader" automatically decide > for any file to be started if it is contiguous and this can be handled XIP > or if it is fragmented and thus needs to be copied ? As things stand, the loader cannot find out whether the ramfs backing store is fragmented or not. What both the kernel binfmt and the loader do at the moment is to ask the kernel to do a private, R/O, executable mmap of the code section, and then the NOMMU mmap deals with copying it or XIP'ing it. > > but since the initramfs packer is in the kernel, that oughtn't to be a > > problem. > > > Do you mean "unpacker" ? Yes, sorry. > I suppose the likelihood that the initramfs generator in the Kernel creates a > fragmented file is very small, as it always starts with an empty file system. And lots of contiguous free memory, yes, but the unpacker uses sys_write(), and the result is subject to the vagaries of the VFS, the VM (what there is of it) and the page allocator. > But OTOH, there might be an issue with file data blocks. The initramfs does > not really need to use a certain block size for the files, but maybe the XIP > loader requests the files to be aligned at certain boundaries. The files are copied into pages attached to the ramfs inodes. They will be appropriately page aligned. David _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
