Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field | Date | Fri, 04 May 2007 12:30:57 -0600 |
| |
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote: >> "H. Peter Anvin" <hpa@zytor.com> writes: >> >>> Eric W. Biederman wrote: >>>> Unlikely. Unless we expect that this offset will come in non-zero. >>>> >>> You might have to worry about that. Historically, the "zero-page" was >>> really just the setup code overwritten, and it's still true for a big >>> chunk of it. >>> >>> One of the major changes in my setup code rewrite is to start out with >>> an all-zero chunk of memory for this. >> >> Well as long as we are in sync with setup.S we are fine. The issue >> is people generating the real-mode data from scratch, when using the >> 32bit entry point. > > Point. I'd like that interface to specify that any undefined fields > should be zero, or we have a hopeless situation on our hands. > > By the way, see the following for the structure definition; prepare to barf: > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=blob;f=arch/i386/boot/boot.h;h=41a16f96ac3476cbd969aabe5e6a792ffe8c64a0;hb=HEAD > > [I intend to move this into include/asm-i386/boot.h, but haven't gotten > that far yet. I just yesterday got the code booting on both i386 and > x86-64, but haven't committed all the include/asm-* mods that went a > long with that yet. I'm also waiting for a Kbuild fix so that the boot > directory can be shared between i386 and x86-64 without requiring a > symlink in the source tarball.]
You should be able to just include linux/screen_info.h instead of duplicating it inline.
I like the use of struct header in the middle of boot_params that seems like a nice maintenance device, although I'm not quite certain about
However you haven't documented the old swap_dev field in struct header. At least rdev still knows about it, so it is probably inappropriate to merge it with syssize. Not that syssize is actually useful for anything in a modern system.
So I just looked at what /sbin/kexec does so we know what to expect. If I have a bzImage I just grab the first setup_sects (i.e. setup.S) and make it the initial linux boot parameters, placing the command line immediately afterwards.
If I just have a vmlinux so I have to fake it I memset x86_linux_faked_param_header to zero, before placing in the values I care about. And the size. 4K aka 1 page. Although I due put the command line at 2K, I think that is actually the historical kernel usage of the zero page.
elilo does something similar but starts with a 16K pages and then backs up 2K for the command line.
Gujin does something similar but also seems to place a command line at 2K.
So short of the first 2K we can reasonably expect new parameters to be zero initialized. Past that we need to be a little more careful.
And 4K seems to be our maximum size for backwards compatibility. Although we use it in a fairly sparse way, so we should be ok.
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/
| |