Date: Sat, 9 Jan 1999 04:53:51 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: mike@smith.net.au (Mike Smith) Cc: rnordier@nordier.com, mike@smith.net.au, abial@nask.pl, jkh@zippy.cdrom.com, dillon@apollo.backplane.com, andreas@klemm.gtn.com, current@FreeBSD.ORG Subject: Re: can't boot from CD and floppy after make release Message-ID: <199901090253.EAA03799@ceia.nordier.com> In-Reply-To: <199901082341.PAA00974@dingo.cdrom.com> from Mike Smith at "Jan 8, 99 03:41:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > I quite like Jordan's suggestion of kzip'ing the loader. The > > compression is not especially efficient: > > > > -r-xr-xr-x 1 rnordier wheel 122880 Jan 3 23:55 loader > > -rwxr-xr-x 1 rnordier wheel 70760 Jan 8 23:05 loader.kz > > > > but boot1/boot2 don't have a problem with loader.kz. > > It's actually not that bad; there's 12k of overhead for the kzip parts, > which is why I was wondering if you had something more compact... Not really. An obvious choice would be something like the pkzip self-extracting archive stub, but I'm not aware of any suitable assembly language code, and would suspect the compactness probably does come mostly from not using C. > > But maybe this isn't the compression you had in mind (I'm assuming > > "when BTX relocates" refers to what the btxldr code does when > > unpacking the composite /boot/loader object before invoking the > > BTX kernel). > > Correct; it was my understanding that this process involved moving the > "payload" data from the load location to the run location, and whether > it might be feasible to unpack it along the way. That's the way it works, so it should be quite possible to do this, given suitable routines. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901090253.EAA03799>