I am currently integrating some polling disk drivers into etherboot. One
for IDE and another for standard floppies. And if it works out
polling cd drivers and polling scsi drivers may be in the future. I am
doing this because I need a general purpose bootloader for LinuxBIOS.
And if I can keep everything small I can use the code on systems even
without LinuxBIOS present.
The current syntax for booting off of disk is to specify:
filename "/dev/fd0"
or
filename "/dev/sda" / filename "/dev/hda"
or
filename "/dev/sda1" / filename "/dev/sda1"
With hda && sda specifying the same disk device.
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.
For ISA devices with architecturally specified fixed I/O address a
fixed name makes sense. fd0 && fd1. For devices like scsi which
are auto-detectable mapping to just something like disk0 makes some
sense. For ide which is somewhere in the middle we can go either way
on the naming convention.
I am tempted to just change the convention to something like:
file:///floppy0/
file:///ide0/
file:///scsi0/
file:///bios_disk00/
file:///bios_disk80/
Or possibbly:
file:///floppy0/
file:///cd0/
file:///disk0/
Where we loose the ability to connect disks to drivers trivially,
and so we much enumerate the drivers when looking for them, so
this is a slower solution.
A third alternative is:
file:///floppy0/
file:///pci00:07.01/1/
file:///bios_disk00/
file:///bios_disk80/
With partitions information coming after the slash. Perhaps,
file:///disk/parition/
And if we start supporting filesystems and I have seen solid
arguments that filesystem code is small enough not to cause to many
problems we could continue the url as:
file:///disk/partition/fs/file
or
file:///disk/partition/file
if we can auto-detect the fs type.
The URL syntax makes it obvious that we are overloading the contents
of the DHCP filename field. Plus it makes the breaks in the kind of
data obvious. Compactness of notation does suffer a little though.
Comments? Thoughts?
My goal is to get this working in the next day or two, and then in
July to setup some configuration alternatives besides DHCP. And in
specifying boot order I really don't want to think of much besides:
removable-media, internal-media, network.
Eric
|
