SquashFS port final report

Hello!

The last 3 weeks have been amazing for our SquashFS port.
We completed directories, files, and symlinks support.
I completed xattrs support too but implementing vnops() hooks for them is
remaining as I was spending this last week on testing our driver.

A more detailed report for each feature:

* Directories - SquashFS directories are simple, we have a header for the
current directory which keeps the count of the number of entries and offset
of block in the Directory table.
Since I was done implementing their traversing functions most of the work
remaining was of implementing VOP_LOOKUP() and VOP_READDIR() hooks.
I spent some time understanding those hooks and implemented them completing
directories read support.

* Files - Now this was a little special, SquashFS files are in fragments
which in turn are in the Fragment table.
Since there wasn't much documentation available I tried to make sense of
SquashFuse source code to understand files.
Once I got its design I began porting them.

However, I got stuck while testing due to constant page faults that
occurred while reading files.
After a lot of debugging, I realized that we cannot use uio vectors
directly for reading and should use uio helper functions like uiomove(),
uiomove_frombuf(), etc... to handle those operations.
Once I used them the issue was resolved.

* Symlinks - This was simple, the symlink target was specified in inode
metadata and all we needed to do was read it.
I quickly implemented the VOP_READLINK() hook and symlinks support was done
as well.

* Extended Attributes - I spent some time understanding SquashFuse's
implementation of them, and after that I ported all necessary functions for
operations like getting extended attributes, getting their value, etc...
The work for implementing VOP_() hooks for them remains since I spent this
last week testing more of our driver.

I am glad I did a lot of testing where I encountered two issues:

1. We can't list the first entry of the root inode.
2. The inode data leaks memory, I don't know how to free that data once we
are not using that inode.
I think the second issue could be resolved soon once I see which function
gets called for freeing inode data.

This is it for this final report.

Thanks a lot for reading it this far.

--Raghav