Re: [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field

["H. Peter Anvin" <hpa@zytor.com>]

Eric W. Biederman wrote:
> 
> You should be able to just include linux/screen_info.h instead of duplicating
> it inline.
> 

I'm working on it!!!!!

> 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.

Actually, ROM bootloaders care about it, which is why it was expanded
out in boot loader protocol 2.04; see the documentation.

> 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.

Oh flippin' hell.  *STABBITY STAB STAB STAB*.

All of which is just evil.  So much for "oh, the definition of the
zeropage never changes, so it doesn't matter."

> 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.

Oh flippin' hell.

> 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.

Sort of.  It's pretty full.

	-hpa
-
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/