Bernardo Innocenti wrote: > John Richard Moser wrote: > >>> Please, build a kernel with the changes you consider useful, >>> and make it available somewhere, along with your proposed >>> config patch. Please make sure that the resulting kernel >>> also still works on QEMU and VMware. >>> >> The base hardware drivers built in supports qemu and vmware? > > Yes, but it doesn't take that much. It's probably just a > pci IDE controller and the vesafb. > > >> Looks like I gotta read up on the wiki about how to rebuild the kernels >> (again). It seems I can alter Grub to do what I want afterwards though. >> (Do I need a developer's key or smth?) > > Yes, you do need a developer key. What is an smth? >
something > Rebuilding the kernel RPM is less than trivial. You may > prefer just building the kernel and then copying it on the > target with a stupid script like this one: > > tar -C $stagedir -czf - . | ssh [EMAIL PROTECTED] tar -C $destdir -xvzf - So glad right now that ssh doesn't allow blank password log-in. So very glad. > > >>> Extra bonus points if you can give hard numbers on memory >>> saving and performance gains. >>> >> Black art ;) > > Well, "size vmlinux" may be a lower bound approximation > for the memory saving. Combined with some /proc/slabinfo > magic you'd get closer. > > As you say, performance is hard to measure. Shell scripts > tend to be good kernel benchmarks because they create lots > of processes, file descriptors, and do a lot of I/O. > Point taken. >>> I'd keep the debug symbols (which shouldn't cost any memory >>> at runtime). >> Possibly not. The kernel runs inside one giant huge page doesn't it? >> 4MiB read-write-execute... > > Not on the Geode: we don't have MTRRs, so I guess the kernel > is being mapped by 4KB pages. > Remove hugetlbfs then. > But anyway, aren't the symbols in a separate ELF section? > So probably they end up in the vmlinuz binary too, but > I've not checked. > > >>> Because of this, I think all the modules required for booting >>> off jffs2 and ext3 need to be linked in :-( >> I think you can omit booting off ext3 for the final product. > > Hmmm, people may like to boot off USB and SD, wouldn't they? > We're talking about a very small saving anyway... Would you boot off the kernel on the flash and then load the system from the USB or SD, or use a kernel on the SD card? > > >> There is load-time consideration to be made about loading everything as >> modules (camera, USB, mouse, all of networking, sound, etc) and leaving >> the essentials (flash, display, keyboard, jffs2). Even if you leave >> networking and all the 100%-always-loaded modules compiled in, however, >> there's no need for things like 30 types of file systems. > > We still have plenty of places where we could recover several > *seconds* of boot time with just minor changes. So I don't think > we should worry too much about module load time, which is probably > very fast. > > In my experience, module load time is usually dominated by the work > being done in the init function, which sometimes involves sleeping > or performing slow I/O (i2c, serial, USB...). This time would also > be spent in the monolithic kernel. > So this raises the question: By parallelizing boot and using an event-driven init system like Ubuntu's Upstart, could you actually get to running application code before loading the modules; and then set up all the hardware while more CPU-bound parts of the boot process run? Sort of bring up the system while all the devices are being initialized, just as long as graphics + keyboard + mouse are up for X to start when it gets there. > >> I'd personally leave out ipv4 and ipv6 and just load them at boot time; >> I'd rather not have ipv6 loaded right now, and ipv6 infrastructures >> should run without ipv4 (some apps will probably complain about no >> 127.0.0.1...); but this is just nitpicking. > > I agree with you. > > >> Really I like a tiny core kernel and a bunch of modules but as >> I said, increases the time needed to boot. > > I once again agree with you, except that I don't think > the load time increase will be problematic on the XO. > -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
