Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >In this case the first 512 bytes was being placed at 0x92200.  One segment
> >of the NBI file had image from 0x90200 to 0x91600 and BSS from 91600 to
> >9A000, so the BSS overlapped the 0x92200 region reserved for the
> >directory.
> 
> I think I understand what happened.  There is a misapprehension here
> that the difference between the image length and the memory length is
> the BSS.  There is no preassigned meaning such as BSS to this gap or to
> any area.  

The meaning of BSS is data is an area of the image is not loaded from
a file.  

> The loaded areas are just areas, not necessarily code, could
> be data, disk images, ramdisk, whatever.  Etherboot is just a memory
> loader + a start address, not a program loader like an OS. It's not even
> a Linux specific loader.  Etherboot does not zero any areas.  If in the
> rare case that a segment is to zeroed before use, it should be arranged
> by running code.  Disk loaders don't zero memory before loading and
> neither should Etherboot.

Disk loaders for kernels do not represent the industry best practices.

Loaders for executables in operating systems represent the industry
best practices.  And under an OS memory is zeroed.
 
The practical problem we have run into with etherboot is people attempting
to load images into areas where there is no ram, or the ram is reserved
by a disk on chip.  I have seen multiple occasions where bugs have popped
on the etherboot-users list where checking the memory areas a tagged image
uses will catch that.  So I am convinced calling prep_segment on
tagged images is the right thing to do.

I do not really care about checking for overlapping areas, (besides
etherboot).  And as we have a way to make all existing images working
there is no reason to implement checking at this time.  Having
overlapping images feels like playing with fire to me.  But I see
no need to force this view on others.

The final issue is how to handle unitialized areas of an image, the
bss parts of a segment.  For ELF it is required that they be zeroed,
and the zeroing is cheap and it increases reproducibility of behavior.
For tagged images we do all of the zeroing before we load anything to
ram so the zeroing it will not cause problems.  If it is felt that the
zeroing is a problem or that the unitialized memory length check is
a problem we can simply not pass that information to prep_segment.

Eric