Re: Grub and the VSTa filesystem

Hello,

 I sent this e-mail already once, but it seams it didn't arrived. So I
try it again. This was my response.

Andy Valencia wrote:

> Ah, thanks for clarifying it!
>
> Well, as far as telling stage1 where to get blocks, what you describe
is
> fine for loading stage2; the boot file will be at offset 0 in the
first
> block. You'd have to make sure you never used this copy of stage2 for
any
> other type of filesystem(!).
>
> If stage2's disk I/O is organized so that the filesystem specific code
has
> to return the block # where the data starts, then yes, it does sound
like a
> problem for the other files. But I was thrown off a bit by the fact
that
> the fsys_table[] has a read_func vector, which the common read()
routine in
> disk_io.c uses. But now I see that there's a NO_BLOCK_FILES which I
guess
> is avoiding this code path? But I still don't see the block map
connection
> in the fsys_table... my snapshot's pretty old, maybe that's the
problem.
>

The current snapshot also uses the block file method for reading files,
but only
the fatfs makes use of it. Every other filesystem (including vstafs) has
its own
**fs_read func vector. Check out the filesys.h header and look for
struct fsys_entry fsys_table[].

>
> But are you *sure* this is really a problem? I thought from your note
on
> Saturday that your stage2 was accessing kernel and modules from
vstafs?
>

That didn't change yet. It is still true. Let's look to it again.

The first step to install GRUB is to dump the stage1 and stage2 with dd
to a
floppy disk. The second step is to make a copy of stage2 into the
(hdX,Y)/boot/grub directory. When the computer boots from the floppy, it
loads
first stage1, then stage1 loads stage2 also from the floppy.
Now we want to install stage1 to the MBR of the harddrive, and we want
this stage1
to use the stage2 we copied to (hdX,Y)/boot/grub. So we invoke the
install
command, which calls read("(hdX,Y)/boot/grub/stage2"). the read
subroutine calls
vstafs_read(addr,len). Vstafs_read() finds from the fs_file structure
where the
stage2 begins and reads it whith devread(sector,offset,len,addr). Each
time
devread is called, a function debug_fs_func is called which makes record
for
stage1 about the start sector and the length of the block which is read
by
devread, but not about the offset. If it would save the offset too, we
wouldn't
have any problems. This way stage1 knows where and how to find stage2.
When next time the computer boots, the BIOS loads stage1 from the MBR.
stage1 then
loads according to its records the stage2. First GRUB tries to find the
menu.lst
file. Read("/boot/grub/menu.lst") is invoked which calls vstafs_read,
which calls
devread. But debug_fs_func is not used in this case, because the call
didn't come
from the install command. Thus we can use the filesystem support.

The offset part in devread is used actually for reading in the header of
the
kernel, for testing the type of it. It tests if it is multiboot
compliant, or
piggy-back, or ... .
Depending on what it is, the stage2 part of the bootloader uses the
correct method
to load the kernel.

>
> Anyway, yes, we'll have to pad all of'em the same way. I still
maintain
> that it'd be screwy, but could be made to work.
>
> OTOH, two changes to vstafs would take care of the problem. The
format of
> the file header could be changed so the 192 bytes of storage are
first,
> followed by the inode-type information. This would handle the case of
short
> files, like a short menu.lst. Second, vstafs could be changed so that
files
> > 192 bytes would start at offset 0 in the next sector. So larger
files
> would waste the 192 bytes, but that's only ~38% waste in the worst
case, and
> drops to less than 5% waste by the time you reach just 4k. vstafs was
coded
> at a time when disk space efficiency mattered a little bit, but since
then
> $$$/MB makes this sort of small-scale optimization moot.
>

I had an idea for these 192 bytes. MS-DOS or may be better is to say
Windows gets
its information about a file from the file extension. These 192 bytes
could do a
similar but extended job. Let's say we have a graphical environment,
which could
save informations in this area. Let's take a sound file as an example.
It could
store the type of the file (sound-file), the format of the sound file
(.au,.wav,...), which application can open it (player, modifier, ...)
and so on.
If the user selects the file and it is executable, these informations
would start
the correct application.

Any other suggestions?

Thomas J. Erdos
Received on Thu Aug 5 17:26:55 1999