On Wed, Jan 30, 2002 at 08:41:04PM -0800, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
>
> >
> > I am reluctant to go with a bootimg like interface because having a
> > standard format encourages people to standardize. Though a good
> > argument can persuade me. I don't loose any flexibility in comparison
> > to bootimg because composing files on the fly is not significantly
> > harder than composing a bootable image in ram.
> >
> > Please tell me if I haven't clearly answered your concerns about
> > being locked into a single image.
> >
>
>
> I have to think about it. I'm not convinced that this particular
> flavour of standardization is a step in the right direction -- in fact,
> it is *guaranteed* to provide significant additional complexity for
> bootloaders, and bzImage support is still going to have to be provided
> for the forseeable future. Since you express that it will basically be
> necessary to stitch the ELF file together on the fly I don't see much
> point, quite frankly; it seems like extra complexity for no good reason.
I'm inclined to agree with Peter here.
For Linux, placing an initrd image with ELF is seriously problematic
since only the boot loader will the necessary information to know
where to put it.
(Note: I suppose initramfs will make some or all of this go away but
as long as initrds are around - which I think will be a long while,
these problems exist.)
- It needs to be placed far enough away from the kernel to avoid
getting overwritten when the kernel starts allocating memory for
stuff at boot time. I had this problem myself with two kernel
monte and a fixed load address for initrds.
- It needs to be placed on free memory. The boot loader would
potentially have access to memory maps to know where not to place
the initrd. I don't know if any do this at this point but I have
had problems with bootloaders dropping initrds in reserved
regions. I ended up switching from syslinux to LILO (or maybe it
was the other way) to get around that.
As soon as you throw multiple architectures into the mix, I think
anything you think you can assume about what memory is reasonable
to use disappears.
Two kernel monte still has this problem. Reading the E820 map or
something like it is on my to-do list somewhere.
I don't think that being able to compose an elf image on the fly would
solve either of these problems since the boot loader needs to make a
relocation decision. Running a linker on the fly would be pretty
nasty anyway, IMO. Nobody is suggesting any kind of dynamic linking
in the boot loader are they?
I like some of the patches that change Linux so you enter in 32 bit
protected mode. Switching back to 16bit mode might cause some trouble
on boards with screwy BIOSes. I did the "stay in protected mode"
thing for two kernel monte because some BIOSes would get hung if I
switch to protected mode and then back again before calling the APM
setup. The trick there is to keep the setup information from the real
mode code and use it for the next kernel. Gross, if you ask me.
I think ELF is overkill for what you're doing with it. It's an
established format but so what? It's not like you'll be able to take
advantage of large existing code base. Sure, ld exists to create your
image but that's not the hard part. The boot loaders would all have
to include new code for this. Also, your patch (for x86 only, it
seems. didn't you have alpha support too?) is far from trivial. In
short, I don't see how using ELF (or creating a new boot format at
all) is going to save much, if any, work.
I have this funny feeling some of the initrd discussion might have
been discussed/addressed elsewhere. I hope I'm not too out of touch
:)
Anyway, there's $.02.
- Erik
P.S. The two second delay in two kernel monte is intentional and
easily removed. It's there to let me glimpse the messages
before it actually does the reset.
-
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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:36 EST