|
From: Anton A. <ai...@ca...> - 2001-08-06 19:03:54
|
Hi FlatCap and list,
It was remarked that TNG is "a fast moving target" and hence difficult to
follow the development. For people interested in following here are a few
notes which I hope might be useful as a starting point with looking at the
driver:
First lets look at the organization of the sources:
ntfs-driver-tng/
patches: kernel patches required to be applied to the kernel
before using the driver. You only need to apply ONE patch, generally best
to use the one most closely matching your kernel, ideally use the exact
same kernel as the most recent patch and apply that. When a patch is so
outdated that it no longer is sufficient to use the current
ntfs-driver-tng, I will remove the patch, so all patches present should
work fine.
linux: the sources/header files for the driver organized the same
way as the kernel tree.
ntfs-driver-tng/linux/
Documentation/filesystems/ntfs.txt: documentation that will be
present in the kernel for the new driver. Currently empty. Lets make the
driver work first and write the docs later. (-;
include/linux/ntfs_*.h: the header files.
fs/ntfs/*.c: the sources
include/linux/
ntfs_fs.h: general ntfs include file. The only one needed to be
included in ntfs sources, it lists all public functions / structures /
types / enums / constants / helper functions / etc for all the ntfs source
files, it includes some common kernel headers already so no need to include
them in the source files themselves, it also includes all the other
ntfs_*.h headers so no need to include them separately either.
ntfs_fs_sb.h: the ntfs super block / volume structure.
ntfs_fs_i.h: the ntfs inode structure.
ntfs_layout.h: the ntfs on disk layout related structure / enum /
etc definitions.
fs/ntfs/
aops.c: address space operations, i.e. readpage and friends,
basically the page cache functionality.
attraops.c: this will be a generic page cache interface to allow
access to "objects" of some description where objects will probably be
defined as "any ntfs on-disk attributes" so that we have a generic
consistent interface for doing this using the page cache. - Not too sure of
what is going to happen here at the moment and the file is not used by the
driver.
attrib.c: attribute handling functions, these operate on
attributes and are hence ntfs specific and so far completely kernel
independent in that they could be taken and thrown into any other os and
still work (with minor modifications for the kernel API changes when our
functions call vmalloc or whatever...). For example find_{first_}attr and
decompress_attr_list functions are there.
debug.c: debugging related functions including my malloc debugger.
Nothing important. The malloc debugger might be thrown out at some point.
dir.c: directory file operations and the functions needed by them
file.c: file inode and file operations. Currently empty.
inode.c: super operations relating to inodes like read_inode,
clear_inode, etc.
mft.c: mft record handling, including the power functions for
mapping mft records and formatting mft records, etc. In the future there
will be functions for resizing the MFT, too.
mst.c: multi sector transfer protection related functions. Also
known as fixup functions.
namei.c: directory inode operations like ntfs_lookup, and in the
future, mkdir/rmdir, etc.
super.c: the super operations and file system definition and
operation read_super. Responsible for un-/mounting the volume, loading and
parsing the boot sector, etc.
time.c: functions to convert between Linux kernel formatted time
and NTFS on disk formatted time.
unistr.c: Unicode string handling and to/from kernel string format
conversion functions, including functions to compare file/inode names and
things like this.
Ok now we have the organization , lets look at what the development status
of the different files it.
There is some stable code which won't be changing in the near future, so it
is safe to start looking at it without seeing your next cvs checkout having
modified it completely... The stable code is in super.c, unistr.c, time.c,
and mst.c. Super.c is complete for the read-only case and it works fine so
bar minor bug fixes (if any) it won't be changing any time soon. Unistr.c
is also stable and I am not planning to change it, except for appending new
functions to it at the bottom of the file. Time.c and mst.c are stable and
completed. Attrib.c and debug.c are probably relatively stable except for
future additions but I have no immediate plans for either. Attrib.c will
need attribute list handling functions built into it at some point later on
but that will not affect the existing find_attr funcions I think. There
will be a different function instead called lookup_attr() which will in
turn invoke find_attr as required. Well, that's the idea at the moment
anyway but I am not going to start on it before the driver is functional
read-only with directory operations and file operations in place so
attrib.c probably will not change for quite a while.
Then there is mft.c which I would like to consider stable, so it shouldn't
change except for additions later on, but it should be sufficient for the
read-only case, so changes might not appear for a while (actually, there
will be one change: the large comment describing map_mft_record_for_read is
A) too long and B) out of date as I wrote it before I wrote the function,
so I need to rewrite it at some point, it's not too important as the code
has all necessary comments I think, but read it if you are bored...). The
code seems to be ok so you can start looking at it. It contains a lot of
page cache internals code so you can learn quite a lot about how the page
cache works by reading it. Basically the map_mft_* functions have built
into them what would otherwise be page cache readpage, block_read_full_page
and get_block functionality. This was necessary due to the multi sector
transfer protection present in mft records and me wanting: A) for this to
be handled transparently to people accessing mft records, B) to be
smp/race/deadlock safe, C) to be fast. The mft has to be handled specially
anyway due to it containing all the inodes themselves so you can't just be
locking the whole thing when reading/writing it or it would be impossible
to access more than one inode at a time which would obliterate performance.
namei.c and file.c are pretty much empty place holders at the moment,
except for the lookup function already having been implemented in namei.c.
And this might be stable but I can't guarantee that as the function it
calls to do the work is under development in dir.c right now...
The other files are not as stable. In particular dir.c and inode.c are
changing a lot right _now_, so probably not much point to look at them.
aops.c is likely to either have a lot added to it or the existing code will
be heavily modified so this is not safe ground either. You can read it if
you need a tutorial on how the page cache readpage function works and what
functions it invokes. It is good reading because it both leaves most of the
work to be done by the kernel on block_read_full_page function and hence
implements our own ntfs_get_block function (for non-resident data attribute
containing files) or does everything itself (for resident data attribute
containing files) so you can learn a lot from it.
For the header files, consider that ntfs_layout.h is 100% stable except for
additions later on when we do more reverse engineering; ntfs_fs.h is
relatively stable except for additions; ntfs_fs_sb.h should be final or
close to final now; and ntfs_fs_i.h is under development so not very
stable, although I do not expect to be changing the existing fields, just
adding more of them as the need arises, but I can't promise I won't be
changing it...
I hope this will get anyone interested started... Questions / comments /
suggestions / bug reports and of course patches are welcome. (-:
Best regards,
Anton
--
"Nothing succeeds like success." - Alexandre Dumas
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
|
