public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "Huang, Ying" <ying.huang@intel.com>, Andi Kleen <ak@suse.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	akpm@linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -v7 1/3] x86 boot: setup data
Date: Tue, 23 Oct 2007 15:52:13 -0700	[thread overview]
Message-ID: <471E7B1D.4050107@zytor.com> (raw)
In-Reply-To: <471E70E0.2090802@goop.org>

Jeremy Fitzhardinge wrote:
> 
> As a general comment, I can't say I'm thrilled about sticking the copied
> setup data at the end of the initial pagetables.  This is already a
> fairly complex area, and changing it touches a surprisingly large number
> of places.  I wonder if there isn't a better way to deal with this
> (possibly by fixing up the generation of the initial pagetables in the
> process).
> 
> Or more simply, define a max size for this data, and copy it into an
> initdata area (which, being initdata, can be quite large without wasting
> lots of memory).
> 

The initdata solution is fairly sensible.  It's easy, and this data 
really isn't expected to grow very fast at all.  Unfortunately we don't 
*have* an initdata bss section at the moment, so a large buffer would 
bloat the kernel binary -- at least the uncompressed one.  One school of 
thought says that this should be fixed :) [*]

However, appending to bss (like the pagetables already are) *should* be 
a reasonable option; what really should be done there is instead of 
replacing init_pg_tables_end with setup_data_end we should except 
additional dynamic data items here, and have an initial_data_end 
variable for the extreme end of any initial data no matter the source. 
It still does touch a lot of places, but at least that way they will be 
fixed once and for all.  It's somewhat questionable if it isn't easier 
for this particular job to just fix the initial bss issue.

Furthermore, on looking through the code again, I see a bunch of 
"init_pg_tables_end + setup_data_len" which really is ugly.

>> +
>> +/* extensible setup data list node */
>> +struct setup_data {
>> +	u64 next;
>> +	u32 type;
>> +	u32 len;
>> +	u8 data[0];
>> +};
>>   
> 
> What are the alignment rules for this structure?  Is it always 64-bit
> aligned?  What about the relationship of len and data?
> 

It's x86, so alignment is soft - it presumably *should* be 64-bit 
aligned, but nothing break if the boot loader doesn't.

	-hpa

[*] A very clean way to do that is to put said section right at the 
beginning of the bss, and move __init_end after it:

   .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
         __bss_start = .;                /* BSS */
	*(.init.bss)
	. = ALIGN(4096);
         __init_end = .;
         *(.bss.page_aligned)
         *(.bss)
         . = ALIGN(4);
         __bss_stop = .;
         _end = . ;
         /* This is where the kernel creates the early boot page tables */
         . = ALIGN(4096);
         pg0 = . ;
   }

On x86-64, this entails moving .data_nosave; it probably can be moved to 
the same relative position as on i386 (although I have not verified that 
that is true.)

  parent reply	other threads:[~2007-10-23 22:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-23  8:06 [PATCH -v7 1/3] x86 boot: setup data Huang, Ying
2007-10-23 22:08 ` Jeremy Fitzhardinge
2007-10-23 22:15   ` H. Peter Anvin
2007-10-23 22:20     ` Jeremy Fitzhardinge
2007-10-23 22:32       ` H. Peter Anvin
2007-10-23 22:52   ` H. Peter Anvin [this message]
2007-10-23 23:26     ` Jeremy Fitzhardinge
2007-10-23 23:18   ` Andi Kleen
2007-10-23 23:55     ` H. Peter Anvin
2007-10-24  3:08       ` Huang, Ying
2007-10-24 22:48       ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=471E7B1D.4050107@zytor.com \
    --to=hpa@zytor.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox