Re: [Etherboot-developers] Q: device naming....

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

Anselm Martin Hoffmeister <an...@ho...> writes:

> > Tenatively I have made the url:
> > file:///floppy0
> > file:///disk0
> 
> > With a +- offset to find the start of the boot file.
> > Which is fine.
> 
> But that doesn't help in every case (e.g. Ms-doze formatted disc, some
> kind of fragmentation taking place). OK, that's exaggeration, nowadays
> you have to format floppies before using them anyway (storing them in
> a box beside my screen. Good idea I hope).

A little more information.  From the offset I do a scan 8K forwards
and 8K bacwards to find the start of the image.  So I don't have
to stomp partition tables and the like.  Plus ELF images can be sparse
so I can do the full lilo thing of memoryizing the disk layout if
necessary.

What I have been after so far is the simplest mechanism needed to boot
the system.  So I have been avoiding filesystem, and partition table
parsing code.  The current driver infrastructure could certainly
support a filesystem parser.

So far I have managed to handle every corner case I can think of
uniformly with just an ELF parser and not a filesystem parser.  Except
for making editing a little easier I have yet to see adding gain from
a filesystem parser, but I have seen a lot more complexity.  A
filesystem parser is certainly needed when you are offering selections
between different kernels, but that is about it.

My requirement is that any setup work on a disk with BSD disk labels,
EFI partition tables, DOS partition tables, no parition tables, or
a partition table scheme written after I flashed the rom chip.

My expectation in the long term is to load Linux or possibly Grub
from the disk to to handle all of the strange issues.

I'm willing to work with any system that works, but I will only code
what makes sense to me.

> Digging inside my 10-year-old "PC-intern 3.0" documentation I found
> out that every dos floppy has a fixed format (well, I knew that,
> but...) with a BIOS parameter block that allows the FAT to be shifted.
> It usually starts at block 1 (offset 0x200), but one can shift that
> while still keeping DOS compatibility. Imagine a disk layout like
> this:
> 
> 0x0000 (512 bytes) Bios Parameter Block*, Loader Code
>        *with FAT-shift for 15,5 kB set
> 0x0200 (15,5 kB) Rest of etherboot
> 0x4000 Begin of FAT, length as needed
> 0x.... Directory
> 
> which should be DOS/Win-compatible. You better not format it (killing the
> etherboot loader), but else it should work as usual floppy, allowing
> you to copy the kernel to this disk from any operating system. Or (if
> you cannot burn a ROM) lock a write-protected disc inside drive A
> which can contain some stuff - better than provoking some Windumb
> choke (if dual-OS or so, as in my "test lab") about that unformatted
> disk in drive A.

Interesting.  I so rarely load etherboot from a floppy I hadn't
thought of that as a normal case at all.

> In case someone writes FAT12 support, this disk could bear a kernel or
> a menu image or so, but mountable and *easily* configurable from
> linux.
> 
> > I am wondering if that naming convention is find of if I should
> > switch to something like:
> 
> > file:///fd0
> > file:///hd0
> 
> You could think about three factors
> - What happens with the second/third disc? -> file:///disk1 ...
> - How to access partitions (hard disk only)? -> file:///disk0/1 ...
> - How to access files there? -> file:///floppy0/vmlinuz,
> file:///disk0/1/vmlinuz -> that's not intuitive.
> I'd prefer
> file:///fd <number> [/<filename>]
> file:///hd <letter> [<number>[/filename[+offset]]] (no number->mbr)
> file:///hd <letter> [<number>][{+|-}offset]

That might be good. But I have a hard time with a 26 drive limit.
Plus I'm not terribly found of fat filesystems.  Having a filesystem
with important information that isn't journaled looks like a problem
waiting to happen.

> Meanwhile, the + offset is ok, but what is - for?

Backwards from the end of the disk.  The most useful feature is
that disk0-0 will scan backwards first.  Logically I have the disk
wrap around so you can have an ELF header at the end of the disk,
and the rest of the image wherever you want on the disk.

> > And on the same subject I am wondering if the old disk code
> > that reads from the pcbios has enough merits to even be kept.
> 
> Could be... If there is some SCSI hardware snapping into the BIOS, it
> could allow SCSI disk access as disk 0x81 or so. Your ide code
> probably doesn't handle that up to now, does it?

Not yet so it is probably worth preserving in some form.  But it will
probably take a complete rewrite, because the current code is not
at all general purpose.

> file:///bd<number> [<number>] while <number> accesses the Bios
> device 0x80+<number> could do (for BiosDisk-access). Floppy support
> through the Bios can become obsolete. If sometime filesystem support
> be added, an uniform interface to disk access could be reasonable. Not
> neccessary for floppy/disk as few people will have
> fat12-disk-partitions, but who knows if for scsi(via Bios)/ide?

Eric