Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 8 Apr 2002 13:16:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 8 Apr 2002 13:16:13 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:7742 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Mon, 8 Apr 2002 13:16:11 -0400 To: Suparna Bhattacharya Cc: "Martin J. Bligh" , linux-kernel@vger.kernel.org Subject: Re: Faster reboots (and a better way of taking crashdumps?) In-Reply-To: <1759496962.1018114339@[10.10.2.3]> <3CB1A9A8.1155722E@in.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: 08 Apr 2002 11:09:26 -0600 Message-ID: Lines: 103 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Suparna Bhattacharya writes: > I have been trying look through this in terms of how it compares with > alternate projects (bootimg, monte etc). As I mentioned in an earlier > mail, crash dump (mcore) relies on bootimg, and I'm trying to decide if > there > could be advantages in using your kexec stuff. My target it to submit the kexec stuff to Linus. I seem to be the only one really actively working on it at this time. I believe my code is the most mature at the moment. The bottom line is the system call needs to get into the kernel. With respect to bootimg there is a strong similarity it how things are done. The big difference is that bootimg interface does everything per page in asking the kernel where to put things and my kexec call is does everything with extents. Which means the kexec data structures are usually much smaller, plus I rely on odd things like PAGE_SIZE. As for monte I can boot other things than the linux kernel. I'm much better at doing the work than publisizing it so my variant isn't quite as well known. That plus I can late to the game. > My main concern of > course is with regard to these BIOS dependent/related issues > since at the time of a crash dump we may not be in quite a "friendly > state". Guess some the linux power mgmt infrastructure or driverfs > should help with sane resets etc (I'm not saying its straightforward > :)). > in the long run. As such how far does your implementation address > some of this BIOS/h/w state handling better ? My code works in SMP. I call the reboot notifier. I probably should run through the pci bus and disable bus masters, but I don't right now. > BTW, some of your other boot enhancements like being able to find out > which memory areas were used or overwritten during bootup sound useful > to me, in being able to estimate the footprint of early boot and > avoiding > using those portions of memory for saving any state (because boot could > stomp over them). Its good to be able to do this in a generic way, > rather > than have the dump code be aware of the ranges for every architecture. That is why I am a fan of ELF kernel images. There is a lot of reasonable resistance to change in that department but it is fairly sane. > > ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.5.7.kexec.diff > > ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec-2.5.7.kexec.log > > ftp://download.lnxi.com/pub/src/mkelfImage/elfboottools-2.0.tar.gz > > type make and see objdir/build/sbin/kexec (work with bzImages) > > I don't seem to be able to access these urls. > The patches I downloaded were from > ftp://download.lnxi.com/pub/src/kexec/* (with the same names). Are these > the right ones ? (your last note mentioned those, but you are saying > that these are the wrong set ... so now I'm a little confused) O.k. My directory structure is just to deep I can't type it straight I meant: ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec/linux-2.5.7.kexec.diff ftp://download.lnxi.com/pub/src/linux-kernel-patches/kexec/kexec-2.5.7.kexec.log And you probably meant: ftp://downalod.lnxi.com/pub/src/linux-kernel-patches/kexec. My other code for cleaning up the boot process is in: ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/linux-2.5.7.boot.diff > Is there one single grand rollup patch with all of the function which I > should look through or try out ? The kexec.diff (instead of the 3 sub patches) is as close as I have gotten. > > The basic kernel interface that is added is: > > > > struct segment { > > void *buffer; > > void *dest_addr; > > size_t len; > > }; > > int kexec(void *start, int nr_segments, struct segment *segments); > > > > Yes, its a good idea to split up the load stage and actual boot/exec > stage. Crash dump needs to have it that way too (the second image > preloaded in advance since we don't want to do any i/o at that > point). Interesting. After a lot of discussion this was essentially the interface we all agreed upon. Preloading wasn't what I was thinking but it works in that sense as well. At least as long as you mlock buffers. The most important piece left with this is to get it accepted into the kernel so people can count on a stable system call interface. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/