> > A specific case where this is necessary would be if the initramfs were > > larger than half of the memory, such as a 2.5GB filesystem with 4GB of > > memory. Without this option, this causes a kernel panic. With this > > option, the user may specify something like 75%, which would allow the > > filesystem into memory, while still leaving enough resources to run > > a functioning system. > > Why would anyone need such a large an initramfs? Thank you for such a quick response, Qian! I really appreciate your question and consideration of my submission. The use case here is a live distribution, where the initramfs is a standard filesystem. It is common for these types of distributions to unpack root into memory. Most of them use SquashFS, and resize shmem using a smaller initramfs first. https://grml.org In my case, I am unpacking straight from the initramfs to alleviate the need for a separate file and packaging everything in an ISO. It very well could be that I am the only person who has ever needed this, but it has been a requirement for my distribution. https://sourceforge.net/projects/gary-os https://github.com/garybgenett/gary-os It is also possible that other live distributions are taking the approach they are because of the current inability to load an initrd/initramfs directly into memory without manually resizing the shmem filesystem first. Since I was in there hacking the feature, anyway, I thought it would be worth submitting. At the least, it should be a "#define", or something. Right now it is a hard-coded magic token. Thoughts? -- Gary
