Re: [Etherboot-developers] [RFC] Booting from disk....

[<ebi...@ln...>]

I've got to go and I won't be back until friday but a quick update.

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

> >To make this work under LinuxBIOS I need to do the following things.
> >1) Move the code for booting an x86 bootsector into osloader.c
> >   So I can boot ELF image directly from disk.
> >
> >2) Modify bootdisk to take a download_kernel parameter.  If
> >   only a stock x86 bootsector is present it will be used see 1.
> >
> >3) Modify bootdisk to call my polled drivers.
> 
> Should be ok. I've had a look and the code around loadkernel is a bit of
> a mess.  Probably what should be done is:
> 
> 1. downloadkernel is misnamed. It probably did the downloading ages ago,
> but really it should be called handleblock. In fact I've just done that
> name change in my version. The symbol's static and so has no ripple on
> effects.

O.k.  I've merged this with os_loader, and called it load_block.

> 2. loadkernel is either a macro or a routine depending on whether
> CAN_BOOT_DISK is defined. It should be taken out and shot.  Ok, ok, just
> taken out. Into another file. Say it's called load.c. It should handle
> the sequencing of bootable devices. It would also separate the kernel
> name from the device name, which I assume is what you mean in 2.

The reference wasn't right but I was thinking along those kind of lines.
I have a first prototype of this currently working.

> 3. floppy.c is also misnamed since it also handles hard disks now. The
> code there should be integrated into some disk driving routines, which
> is what I assume you are creating. I would like to see the disk modules
> optional so that those who don't use them don't have to pay for it.

Agreed.  I'd like to make them as optional as the NIC drivers.
One of the great things with etherboot is that it is small and while I
want to enhance it, I don't want to loose that property.
 
> 3. Not sure how osloader comes into this. os_download is called from
> handleblock (formerly downloadkernel). Does it have to be involved?

If I push the functionality for handling an x86 bootsector into
os_download, I can load either an ELF image a tagged image or
an x86 bootsector from a raw partition with the same code. 
 
> The convention for specifying the driver type, partition and filename is
> another can of worms. However, it's delegated to the disk driver. All
> load.c has to know is which driver to call and to pass the tail of the
> path to it.

To some extent I agree.  But mostly I prefer to keep policy issues out
of the drivers.  But since I don't plan on implmenting partition,
and fs handling just yet I'm o.k.

There are lots of bits of etherboot that are a slightly of a messy,
and that makes it harder to enhance.  So while I walk through making
some enhancements.  I'm going to be cleaning up things as I go along.

One big thing I want to see is having drivers be fully self contained
so that to add a new driver consists solely of writing a driver file,
and adding an entry to the list of drivers.

Recently I worked with memtest86 and picked at all of the things
that irritated me with it, and then released it.  That turned out
fairly well.  My goal is to do something similiar with etherboot.

Lots of small changes but a big end result.  So for the moment at
least I'm actively developing it.

Eric