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