|
From: Anton A. <ai...@ca...> - 2001-11-25 03:32:18
|
(Jeff, this is a copy from irc session in case you didn't get to read it and I have added a few more comments, too. I have cc:-ed linux-ntfs-dev, too) About attribute list reading. The current ntfs tng cvs already reads in the attribute list of each inode (assuming the attribute list is non-resident otherwise there is no need) and stores both the run list and the attr list value itself in vmalloced memory inside the ntfs specific parts of the inode. And there are two bits in the "state" field of the ntfs specific inode to indicate that an attribute list is present and that it is non-resident. The next step is to complete attribute lookup function and attribute lookup external function. I have them reverse engineered but they need rewriting for us and porting to the kernel/current code base. You can have a look at the reverse engineered stuff in cvs: linux-ntfs/libntfs/attrib_RE.c Basically the ideas behind those are that we stop using find_attr in the code. We always use lookup_attr instead. (Except in special cases where we are going to actually fiddle with the attributes by hand, i.e. in low level code) lookup_attr then does the right thing by noticing whether an attribute list is present or not and doing the correct call into find_attr or lookup_external_attr to find the attribute. Once it finds it, it returns the attribute in an extended search context. The search context has to include the current state of the search and any mft records that were mapped in the process. We then need a cleanup search context function which will unmap everything in the search context. I am even thinking of having a slab cache for search contexts for efficient allocation/deallocation. The context is necessary so you can find the first part of an attribute and then immediately find the next one. For example when $DATA is split into several attribute extents, you need this functionality. The advantage of doing it this way is that attribute lists are 100% transparent to callers of lookup_attr(). It always returns the actual attribute and the caller has not to care whether the attribute came from the mft record they submitted in the search context or whether it came from an extension mft record referenced by the attribute list. ---end of irc session--- In fact you will see the reverse engineered function (lookup_attr) actually will happily read in the mft record first so we can do the same. This means the caller doesn't even need to call map_mft_record_for_read, they just call lookup attr with the struct inode * which they want to search and the mapping is done completely transparent and the state is again stored in the search context. That makes for quite an extensive search context but considering how easy it makes the life of the caller it is well worth it IMO. What do you think? Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- 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/ |
