Kexec support 2.4?
YH
-----Original Message----- From: Richard Smith [mailto:smithbone@gmail.com] Sent: Wednesday, January 11, 2006 7:40 PM To: Werner Almesberger Cc: Ronald G Minnich; kboot-general@lists.sourceforge.net; linuxbios@openbios.org; Fastboot mailing list; Lu, Yinghai Subject: Re: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
Getting 1 MB is as good as we can do for now.
Hmm, that'll get awfully tight :-(
Its tight but can be done. I've build a embedded system that booted out of 1Meg of flash. 2.4 kernel+initrd that loaded a pcmcia module for the wireless adapter in the system dhcp'ed up the network and then pulled down a larger ramfs and kexec'ed into it. I had to build a custom version of the pcmcia tools with uclibc only doing the absolute minimum to get the wireless interface up.
IIRC I only had a couple of Kb left over.
-- Richard A. Smith
On 1/12/06, Lu, Yinghai yinghai.lu@amd.com wrote:
Kexec support 2.4?
Back when Eric started it did. 2.6.x was still very new. This was several years ago.
-- Richard A. Smith
Richard Smith smithbone@gmail.com writes:
On 1/12/06, Lu, Yinghai yinghai.lu@amd.com wrote:> Kexec support 2.4?> Back when Eric started it did. 2.6.x was still very new. This wasseveral years ago.
2.4 is still fairly easy to get going. The problem is all of the related hardware fixes which are hard to identify and back port.
Eric
If you could provide a roadmap on how to do this, or even better have a chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would _really_ be useful.
2.4 is a smaller kernel than 2.6, and for supporting legacy systems that only boot from floppies, I regularly use it on a single boot floppy, using uclibc and busybox, along with e2fs tools and also dialog, for lots of support software we develop. I guess we have a thing about getting it all on one floppy, but it would be helpful if we could jump into a 2.6 kernel on CD, for some situations. Legacy systems won't boot from CD in most cases.
Steve G.
Eric W. Biederman wrote:
Richard Smith smithbone@gmail.com writes:
On 1/12/06, Lu, Yinghai yinghai.lu@amd.com wrote:> Kexec support 2.4?> Back when Eric started it did. 2.6.x was still very new. This wasseveral years ago.
2.4 is still fairly easy to get going. The problem is all of the related hardware fixes which are hard to identify and back port.
Eric
On 1/13/06, Steve Gehlbach steve@nexpath.com wrote:
If you could provide a roadmap on how to do this, or even better have a chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would _really_ be useful.
2.4 is a smaller kernel than 2.6, and for supporting legacy systems that only boot from floppies, I regularly use it on a single boot floppy, using uclibc and busybox, along with e2fs tools and also dialog, for
Is is smaller than a linux tiny kernel?
-- Richard A. Smith
Not sure, I am not familiar with that. But 2.4.32 comes in at around 948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card drivers. Busybox with most programs enabled along with dialog, mke2fs and e2fsck spliced in as addons, is about 720K (uncompressed), and the whole thing with a few of our shell scripts is about 40K under the 1.44M limit.
Steve G.
Richard Smith wrote:
On 1/13/06, Steve Gehlbach steve@nexpath.com wrote:
If you could provide a roadmap on how to do this, or even better have a chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would _really_ be useful.
2.4 is a smaller kernel than 2.6, and for supporting legacy systems that only boot from floppies, I regularly use it on a single boot floppy, using uclibc and busybox, along with e2fs tools and also dialog, for
Is is smaller than a linux tiny kernel?
-- Richard A. Smith
On 1/13/06, Steve Gehlbach steve@nexpath.com wrote:
Not sure, I am not familiar with that. But 2.4.32 comes in at around 948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card
Linux-tiny may be able to beat that. The number in the orginal paper was a TCP/IP, ext2, PCI and 1 network card in 363k.
Give it a whirl and report back your results.
http://www.selenic.com/linux-tiny/
-- Richard A. Smith
Well, linux-tiny does do better, but so far it seems to have too many bugs in 2.6.14 for serious work. Many config setting I tried give compile errors, which seem to be related to unenforced dependencies, and even when I can get it to compile I have never had it actually work, erroring out in the boot process with "bad gzip magic number". But I have gotten unpatched 2.6.14 to work, with kexec, and successfully jumped into knoppix from a single floppy boot with all the tools I need. Thanks for the help, right now the -Os compile switch gets me there, and I will keep monitoring linux-tiny for additional progress.
Steve G.
Richard Smith wrote:
On 1/13/06, Steve Gehlbach steve@nexpath.com wrote:
Not sure, I am not familiar with that. But 2.4.32 comes in at around 948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card
Linux-tiny may be able to beat that. The number in the orginal paper was a TCP/IP, ext2, PCI and 1 network card in 363k.
Give it a whirl and report back your results.
http://www.selenic.com/linux-tiny/
-- Richard A. Smith
Steve Gehlbach steve@nexpath.com writes:
If you could provide a roadmap on how to do this, or even better have a chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would _really_ be useful.
2.4 is a smaller kernel than 2.6, and for supporting legacy systems that only boot from floppies, I regularly use it on a single boot floppy, using uclibc and busybox, along with e2fs tools and also dialog, for lots of support software we develop. I guess we have a thing about getting it all on one floppy, but it would be helpful if we could jump into a 2.6 kernel on CD, for some situations. Legacy systems won't boot from CD in most cases.
I did some measurements in early 2.6. Using the patches from the linux tiny tree. 2.6 was comparable with 2.2 and noticeably smaller than 2.4.
Basically my conclusion is that 2.6 was only bigger because it had more stuff in it by default and almost all of that stuff is configurable.
Eric
Eric,
are you sure the linux tiny will be in 2.6.16?
YH
Thanks for the info. I will give it a try. I actually had linux-tiny in my list of links to get to and read, and hadn't got there yet. A few months ago I just took a straight forward approach of clicking the same things I had in 2.4 for 2.6, and it built out at about 1300K. It was so far from 900K that I didn't look any further. Things that I need that add a lot are for example usb mass storage and also ext3 but I am not sure how much that adds.
I might also mention that I have always left out module support, and linked in 5-10 most popular network drivers. There seems to be no savings in space since you would need all the modules on the disk anyway. Never had any problems in the drivers finding their card or conflicting. The idea is that it can be used on a wide variety of hardware without configuration. Maybe others have a better approach I am open for ideas.
Steve G.
Eric W. Biederman wrote:
I did some measurements in early 2.6. Using the patches from the linux tiny tree. 2.6 was comparable with 2.2 and noticeably smaller than 2.4.
Basically my conclusion is that 2.6 was only bigger because it had more stuff in it by default and almost all of that stuff is configurable.
Eric
Steve Gehlbach steve@nexpath.com writes:
Thanks for the info. I will give it a try. I actually had linux-tiny in my list of links to get to and read, and hadn't got there yet. A few months ago I just took a straight forward approach of clicking the same things I had in 2.4 for 2.6, and it built out at about 1300K. It was so far from 900K that I didn't look any further. Things that I need that add a lot are for example usb mass storage and also ext3 but I am not sure how much that adds.
I might also mention that I have always left out module support, and linked in 5-10 most popular network drivers. There seems to be no savings in space since you would need all the modules on the disk anyway. Never had any problems in the drivers finding their card or conflicting. The idea is that it can be used on a wide variety of hardware without configuration. Maybe others have a better approach I am open for ideas.
The two interesting pieces for your style of configuration are: 1) The -Os work that has been going on recently, I think I have heard 10% reduction for that. 2) Careful selection of which compiler you are using as that makes a noticeable difference. 3) Look under CONFIG_EMBEDDED and possibly elsewhere for options you don't need and can turn off. CONFIG_EMBEDDED also has some smaller alternatives for some of the common features.
You might also grab ext2 instead of ext3. When clean either will work.
Eric
Thanks hugely for the suggestions. I need ext3 since this build is also used for rebuilding or fixing filesystems but you make a good point.
One of the errors that I made previously, and I appreciate everyone pointing out that 2.6 was not necessarily larger than 2.4, is that I did not carefully go down each tree in the menuconfig. At the time I did not realize that 2.6 had so many options and buried menus.
I put in the linux-tiny patch for 2.6.14, and after working on the config for an hour or so, I got it down to 1020K with gcc-3.3. Based on Eric's suggestions, I took the same config and put it on a system with gcc-4.0, put in the -Os option, and got a size of 814K! This is with all I need in the kernel and the kexec option. If you recall my limit is about 950K-960K so this is perfect. I am assuming the kexec tools needs clib so I will have to splice this into busybox somehow but hopefully it won't add too much.
I haven't made sure it all works yet, but it is close enough to start debugging. Thanks tremendously for all the help.
Steve G.
Eric W. Biederman wrote:
The two interesting pieces for your style of configuration are:
- The -Os work that has been going on recently, I think I have
heard 10% reduction for that. 2) Careful selection of which compiler you are using as that makes a noticeable difference. 3) Look under CONFIG_EMBEDDED and possibly elsewhere for options you don't need and can turn off. CONFIG_EMBEDDED also has some smaller alternatives for some of the common features.
You might also grab ext2 instead of ext3. When clean either will work.
Eric
gcc-4.0, put in the -Os option, and got a size of 814K! This is with all I need in the kernel and the kexec option. If you recall my limit is about 950K-960K so this is perfect. I am assuming the kexec tools needs clib so I will have to splice this into busybox somehow but hopefully it won't add too much.
If you want to try and go further then:
http://redhat.com/~mingo/debloating-patches/
They are for 2.6.16 though so you will need to go into developent territory. Ingo claims a extra 5% or 6% size reduction. Its not clear if this is with or irrespective of the tiny patches.
-- Richard A. Smith
steve steve@nexpath.com writes:
I put in the linux-tiny patch for 2.6.14, and after working on the config for an hour or so, I got it down to 1020K with gcc-3.3. Based on Eric's suggestions, I took the same config and put it on a system with gcc-4.0, put in the -Os option, and got a size of 814K! This is with all I need in the kernel and the kexec option. If you recall my limit is about 950K-960K so this is perfect. I am assuming the kexec tools needs clib so I will have to splice this into busybox somehow but hopefully it won't add too much.
It looks like Werner already has it working against uclibc. /sbin/kexec is not especially demanding of libc.
Eric
kexec compiles fine under uclibc tool chain with about 196K dynamic exec. That compresses to 61K so I think it will fit.
Steve G.
Eric W. Biederman wrote:
steve steve@nexpath.com writes:
I put in the linux-tiny patch for 2.6.14, and after working on the config for an hour or so, I got it down to 1020K with gcc-3.3. Based on Eric's suggestions, I took the same config and put it on a system with gcc-4.0, put in the -Os option, and got a size of 814K! This is with all I need in the kernel and the kexec option. If you recall my limit is about 950K-960K so this is perfect. I am assuming the kexec tools needs clib so I will have to splice this into busybox somehow but hopefully it won't add too much.
It looks like Werner already has it working against uclibc. /sbin/kexec is not especially demanding of libc.
Eric