ollie <[EMAIL PROTECTED]> writes: > 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. I agree that a single filesystem does not add too much bloat. The general case of supporting all filesystems does add bloat.
Adding a filesystem layer does add a lot of restrictions. It insists you have a boot partition. It insists that boot partition have a specific filesystem on it. It insists you have a specific file on that boot partition. If you have support for booting off an arbitrary file on the filesystem, and selecting amoung them I'd love to hear about it. > 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). O.k. very nice. > >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. Possibly #3 is just to hard-coded. And I am willing to consider a better solution. Especially for the interactive case. What I like about #3 is that - It is well proven it is what dos has been doing for years just slightly extened so it can load a full os. - It allows you to use arbitrary partitioning schemes and arbitrary filesystems. So it doesn't break if your users want to run reiserfs over lvm. - Using 64bit ELF you can place your ELF image (except it's header) anywhere on the disk. Eric
