Re: GSoC-2016

[christos%astron.com@localhost (Christos Zoulas)]

In article <CAFy_ZFBjSFih4UUp6dzq6-62xDiByXm0=CYfja5VJPk=+GiShg%mail.gmail.com@localhost>,
HRISHIKESH GOYAL  <hrishi.goyal%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>Hi
>
>I am trying all the ways to get htree write fixed. But there are few things
>in code that conceptually seems wrong like while loading a vnode for a
>given inode-number, code doesn't load all the informations in the struct
>inode.  Specifically while reading a disk-inode for given inode-number
>returning vnode of corresponding disk-inode, which also has a pointer to
>struct inode of corresponding disk-inode. All the common(with disk-inode)
>fields of struct inode must be initialized with their corresponding  value
>in disk-inode.
>
>Another thing is since in NetBSD ext2fs share inode struct with ufs. But
>the i_flags bits may be representing different functionality in both. so I
>can't directly map e2di_flags in struct ext2fs_dinode to i_flags in struct
>inode.
>
>ideally we should be able to do  inode->i_flags=
>ext2fs_dinode->e2di_flags
>likewise for other common fields
>
>Should I create a separate inode struct for ext2fs? That will rise the code
>to a nice structure, but for that we will need to do many other changes in
>the code that may cross gsoc time limit.

I don't think we are there yet. What other fields need mapping other than
flags? For flags you can write 2 functions thart convert the bitmaps from
one to the other and backwards.

christos