Date: Fri, 3 Oct 2003 19:41:38 -0700 (PDT) From: "Jason C. Wells" <jcw@highperformance.net> To: chat@freebsd.org Subject: Limitations of Crunchgen Message-ID: <Pine.BSF.4.44.0310031907120.47935-100000@s1.stradamotorsports.com>
next in thread | raw e-mail | index | archive | help
I am working on a picobsd-esque system. It works so far. So far I have only crunched binaries of /bin and /sbin with statically liked libraries. The system is halfway between picobsd and minibsd. The intent is to run specialized servers, i.e. DNS only, mail only, KDC only. The system would be bigger than the floppy sized picobsd and so storage is less limited at 64MB of compactflash, but still pretty small. Is there a limit to how much code I can crunch into a single binary? Are problems likely to creep into the system in mysterious ways with massive crunching? What are some of the operational issues of running a system with /bin,/sbin,/usr/bin,/usr/sbin crunched as one big binary? *** The rest is fluff, but I wrote it already, so you can read it if you like. *** If a binary turns out to be 4MB, it will take some time to load. If the binary never gets LRUd out of main memory, it will never be reloaded. That sounds pretty cool to me. Most of the programs in the crunched binary would rarely be run anyway. For example, once bind loads up and reads its zone files, it really doesn't need much disc access. The only time programs would be run is when I login to poke around. I am thinking it will be really nice to read from compactflash once and only once during execution of the first program and then never have to read from "disc" again. Is this a correct assumption regarding how this will work? /bin and /sbin are really no problem. When I started to look at doing this /usr/bin, I started thinking that maybe this is too much stuff to crunch into one big binary. I have read that swapping on compact flash is verboten. I read up on minibsd. I don't like the notion of dynamic linked /bin and /sbin. Plus I am not getting anywhere near the 6.7MB of extra storage consumption by linking statically that that author claims. Well, I have gone and done it. This email risks getting no replies because it's too damn long. I'll give it a go, then come back in a couple days with a two paragraph message. Later, Jason C. Wells
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.44.0310031907120.47935-100000>