Eric W. Biederman wrote
>
>O.k. nice to know. We should probably share around these patches
>more so they can get in the core etherboot. Ken Yap is fairly responsive
>to accepting good code. Occasionally he releases a little slowly but
>otherwise all is good.
>
>What I am envisioning, and have implemented in proof of concept form is
>to add IDE and floppy support to etherboot in the following way.
>
>1) No filesystem code.
>2) DHCP controllable with filename "/dev/hda" or filename "/dev/fd0"
>3) Scan for an ELF header through the first 4KB of disk (as elfboot.c does).
> - This allows us to still use the pc partition tables.
> - This allows us to do the lilo like trick of loading images
> in filesystems by memorizing their locations on disk.
> We would memory the location of an ELF bootable by writing a ELF header
> the 63 unused sectors normally found on a disk right after the partition
> table.
> - Equally we can just have a ELF bootable image at the start of the disk.
>
>This all works with the IDE code as I integrated it into LinuxBIOS already.
>
No, adding a filesystem layer does not add too much bloat. For what I
have locally,
ollie bin32 425:size disk_io.o fsys_*
text data bss dec hex filename
6720 120 36 6876 1adc disk_io.o
2413 4 12 2429 97d fsys_ext2fs.o
2125 13 4 2142 85e fsys_fat.o
The disk_io.c is a little bit bloated because it has a very stupid
partition table
and filename (boot path) handling code. They are also contaminated with
some grub stage1/stage2 logic. BTW, the 50+KB etherboot .ebi aslo has
the SiSFB Lite built-in to turn on the VGA (and font included).
>
>There is real value in building a GRUB like loader but I currently do not
>see the need to understand filesystems currently. If I am going to bloat
>I will probably use the Linux kernel. I can put it on as a bootloader
>on my disk and switch between loaded images.
>
I think it is a good trade off to add filesystem support. The #3 of your
proposal
is just too "hard-coded" which I really don't like.
Ollie
