Thanks for doing this work, Stefan. A few things. First, the ext2 
reading code is not handling revision 1 ext2 filesystems. Revision 1 
filesystems split the 16 bit length name_len field of the dirent into 
two 8 bit fields, "file_type" and "name_len". Milo still uses the 
ext2_dir_entry structrue and reads name_len as a 16 bit value, so you 
get file lengths that are extraordinary long. For example, the 'etc' 
entry of the '/' directory is read to be 515 bytes long. Since it's 
checking to see that the lenths of the file you're looking for and the 
dentry that you're looking at have the same length, nothing matches 
and MILO fails to open the file. 

Of course, 515 is just 0x0203, showing that it is a EXT2_FT_DIR (type 
2) with entry length of 3. All we really need to do is a lot of 0xff 
masking whenever you use a dentry->name_len. 

There seems to be a problem reading 4096 byte block sizes. I've not 
tracked down the exact problem here. 

Stefan - could you send the .config of the kernel that you built 
against? I'm having trouble with symbol resolution, probably because 
I have too many drivers/subsystems turned on. 

Thanks again. 

Matt 
msw@redhat.com 


MILO should probably be using libext2. It should handle weird block 
sizes and older filesystems just fine... 

http://web.mit.edu/tytso/www/linux/e2fsprogs.html 

-- 
Jeff Garzik              | Just once, I wish we would encounter
Building 1024            | an alien menace that wasn't immune to
MandrakeSoft, Inc.       | bullets.   -- The Brigadier, "Dr. Who"

-------------------------

Yes, on the other hand it might make milo even bigger (talking about 
binary size, wich definitely is a problem keeping linload,milo,kernel 
on a floppy). 
I did a patch for aboot to run fine with the "filetype" and "4k-blocksize" 
which should be easily adapted to the ext2-code in milo, they basically 
use identical sources for this (ftp.suse.com/pub/people/ro/aboot). 
