Re: Minix 3 subpartition/filesystem patch

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]

On 07/19/2010 06:39 AM, Fam Zheng wrote:
> Hi all,
>
> As a project of GSoC of MINIX community, we have almost completed the
> work making MINIX 3 Multiboot compliant. I believe it would be very
> helpful for us if GRUB can handle MINIX 3's subpartition and
> filesystem correctly in the future, so I've made a patch for reading
> the currently in use MINIX subpartition, so as to make GRUB Multiboot
> access the OS kernel image. This patch has already been used for a
> while in our development, to load and test MINIX kernel, and I think
> now it's ready to be submitted here.
>
Why not multiboot2? It supplies a structure which is easier to copy and
move around. If you need any multiboot2 amendment please contact.
> There are two parts of the patch. First part is on fs/minix.c which is
> changed to support the latest MINIX FS version 3 (previously only
> version 2 is supported). The other part is on partmap/msdos.c, the
> changes are made for the following reason:
>
Please don't mix 2 patches. Patch for subpartitions is
copyright-insignificant so can go directly in. Minix3fs on the other
hand would need some papers.
> AFAIK there are two kinds of subpartition, one is from BSD, the other
> is MINIX. With the latest trunk source, the subpartition is found by
> GRUB, partition names like (hd0,msdos1,msdos1) can be recognized, but
> the problem is the 'start' of partition: in the partition table for
> MINIX subpartitions (the table found at the end of the first sector of
> (hd0,msdos1) in this example), the field "start" is treated as an
> relative value, where for MINIX it is actually an absolute one.
Common brain damage. NetBSD has the same.
+         if(disk->partition && e->type ==
GRUB_PC_PARTITION_TYPE_LINUX_MINIX)
+               p.start -= disk->partition->start;
The criteria is probably wrong unless minix subpartition label mixes
relative and absolute offset. Instead of this you have to check that
container is msdos itself and that its type is minix. We'll need a
similar check in bsdlabel too.

We use gnu and not bsd indentation. Please adjust your patches.

Patch for minix3 fs breaks any other version of minixfs. E.g.
-  grub_uint16_t inode_cnt;
+  grub_uint32_t inode_cnt;
offsets all other fields.
minix.mod must be split into 3 modules: minix1.mod, minix2.mod and
minix3.mod with mostly shared source code. Look at ufs/ufs2 and
afs/befs/afs_be/befs_be for how to do it.
>
> To solve this inconsistency, I patched partmap/msdos.c to convert the
> value stored on harddisk to relative simply by a subtraction, this
> happens only when a MINIX type (type field == 0x81) subpartition is
> encountered.
>
> Thank you.
>
> -- 
> Best Regards!
> Fam Zheng
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]