On Mon, 2006-11-27 at 23:58 +0530, Moinak Ghosh wrote: > Erast Benson wrote: > > On Mon, 2006-11-27 at 12:10 +0100, Martin Bochnig wrote: > > > >> Darren J Moffat wrote: > >> > >> > >>> Which build is this based on ? > >>> > >>> -- > >>> Darren J Moffat > >>> > >> More importantly, which ISA/ARCH is it based on. > >> He forgot to mention that most important piece of information. > >> > >> It must have been sparc, because sparc doesn't use grub so far. > >> To boot Grub based "newboot" flavours of Solaris x86/x64 (and therefore > >> 2.10_U1 or higher, or 2.11_b15(circa) or higher) with only 64MB of > >> physical mem, one needed to have a _very_ small custimozed boot archive. > >> See Moinak Ghosh's good work to shrink that down beyond the limits. > >> (The boot archive is pre-(down)-loaded and must completely fit into ram.) > >> > >> I doubt DC has worked on that. > >> It can only be sparc because of that. > >> > > > > Likely you are right. > > > > I wonder if we could do the trick similar to what Linux kernel is doing > > with initrd? i.e. free up ram disk space for applications after kernel > > is initialized and HDD root is mounted. > > > > There are more possibilities in this area. I am looking at replacing > /sbin/init with a > shell script that mounts the CDROM first and then execs the real > init. This will allow > putting most of the /lib and /sbin and others onto CD. If I use bash > as the shell, then > only libc and libm need to be present on the ramdisk in /lib. > > So the size of the ramdisk should be reduced by around 28MB (from 62 > to 34). > An additional possibility is to port UnionFS from FreeBSD (+patches) > which should > allow more kernel modules to be moved onto CD. > > However all these might impact bootup performance a bit.
While I agree that all the above is possible. I'm not sure that it is the cleanest possible solution. It all looks like a very nice hack to me. I think that for the long term we need to free up ram disk memory dynamically and release all this space for apps. -- Erast _______________________________________________ opensolaris-discuss mailing list [email protected]
