On Thu, Aug 6, 2009 at 6:16 PM, Aruna Medhekar <sparx2...@gmail.com> wrote:
> Sir, > We are extremely sorry for the error in the previous message.We wish to do > a project in tux3 filesystem.Please let us know something that you think is > within our scope. > Thank you ! > > FYI, Recent mail from Daniel: Anyway, let me offer two beginner projects: 1) Add success checks to unit tests 2) add a "check" command to the tux3 command Unit test success: - Unit tests are compiled as main programs in tux/user, that include kernel files and sometimes other userspace files as source text, for example: #include "kernel/filemap.c" - Currently, unit tests just run and produce output. If something is wrong an assertion may trigger, or it may segfault, or the tracing output may be unreasonable. - It would be better if the test concluded with a test to see that then final result is as expected, according to the operations that were performed. The main program should return 0 with no warning if results are correct, otherwise print a warning and return 1, a failure code for a shell script we may add later. Tux3 check: - Command form should be: tux3 check <volume> [<file>] - As a first approximation, should just walk the filesystem tree from the root as Hirofumi's tux3graph program does, checking that physical block pointers lie within the volume and that leaf nodes of the inode table and file data subtrees pass the leaf checks already implemented. - Later, this walk will build a bitmap map of used blocks so that we can check that there is no lost space in the volume and that actual used/free matches the allocation bitmaps. When building the bitmap we can also check for multiple pointers to the same block, which are not allowed in tux3.
_______________________________________________ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3