On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote: [..] > > If we are ok with the idea of passing executables and initramfs to > > kernel, then kernel can do the placement. That means fields "mem and > > memsz fields of kexec_segment will be free. We can possibly overload > > memsz field and pass flags to represent segment type. This will happen > > only if user chooses kernel as bootloader functionality. > > Which sounds nice initially but I don't think the notion of the kernel > being a general purpose bootloader holds up to well. It doesn't provide > an easy place to put all of the weird cases. > > If we are going to pass in a file it probably makes sense to do a > variation of kexec_load that passes in a file descriptor, a filename > could work but I don't think we want those races. Can we use execve() style filenames. I am not sure what races are you referring to. > > But then we get how do we pass in a different kernel command line and > an initrd. Things that were simple start quickly becoming complex. Can we take more than one filename arguments. Maybe an array of filename arguements. And another array of arguments. SYSCALL_DEFINE2(kexec2, const char __user *const __user *, filenamev const char __user *const __user *, argv) This will allow passing filenames of both kernel and initrd and also allow passing arguments. Arguments will also include command line. Not asking user space to read in the file will help avoid loading one extra copy of kernel in memory. One difference here is though that we will have to allocate kernel memory for full kernel image and full initd and if images are big, it can lock down lot of kernel memory and in fact can trigger OOM on many processes. I guess that's an issue with existing kexec() interface too, so nothing new here. This is like re-designing the kexec/kdump and I really wish there is an easier way to handle the case signed kernels. Thanks Vivek
