thanks! your reply it's very useful to me!! yes, it' security purposes! i just trust dom0 , but not trust domU. i want to save the blocks of improtant files of domU into dom0, when write operation happend in domU, domU will send the request struct , which contain the sectors need to write, to dom0, next, in dom0 compare the sector number. if the sector numbers is which i want to protect, the write operation will be stoped by dom0. even if intruder get the root privilege in domU, he can't change the file (for example :files in /bin dir) which i protected. now, another question confused me: in the request struct , there are two group of sector info. and i don't know what's the diff between them. and how to get the all sector numbers of a request for a file? sector_t sector; /* next sector to submit */ unsigned long nr_sectors; /* no. of sectors left to submit */ /* no. of sectors left to submit in the current segment */ unsigned int current_nr_sectors; /***************************************************************************************************/ sector_t hard_sector; /* next sector to complete */ unsigned long hard_nr_sectors; /* no. of sectors left to complete */ /* no. of sectors left to complete in the current segment */ unsigned int hard_cur_sectors; Thanks very much! <div class="gmail_quote">2009/6/2 Theodore Tso <<a href="mailto:tytso@mit.edu">tytso@mit.edu</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Tue, Jun 02, 2009 at 08:05:48PM +0800, Zhang Shukun wrote: > thanks for your answer! > > my goal is : in kernel space , get the specific disk block numbers(or sector > number) of a file(such as /bin/ls). > > because i want to use the block number in DomU, which is a VM in xen. when i > read or write a file in DomU, front end driver will send the block number to > back-end driver Dom0 , and then in dom0 i can check if the block could be > write or not. </div>The filesystem does that already (send the block number to the back-end driver) when it wants to read or write the block form the filesystem. If the goal is to do this for security purposes, you should be calculating the inode->block mapping in dom0, *not* in domU. After all, if you don't trust the domU to enforce the normal security restrictions which the kernel enforces, why would you trust domU to give you the correct inode->block mapping so that dom0 can do some kind of security access check? In any case, to answer your specific question, to convert from a struct inode to a struct ext3_inode_info, *if* you know that a particular struct inode from an ext3 filesystem (as opposed to an ext2 filesystem, ext4 filesystem, FAT filesystem, a networking socket, etc.) you can use the EXT3_I function to get from an struct inode to struct ext3_inode_info: static inline struct ext3_inode_info *EXT3_I(struct inode *inode) { return container_of(inode, struct ext3_inode_info, vfs_inode); } What happens here is that the struct inode is actually embedded inside the ext3_inode_info structure, and what is cached is the ext3_inode_info structure. So container_of() basically takes a pointer to the struct inode, and substracts the offset from the beginning of ext3_inode_info and the vfs_inode element in ext3_inode_info, to get a pointer to the struct ext3_inode_info. If this isn't an ext3 inode, though, your kernel code will likely crash from the nonsense it will get when it tries to interpret data that isn't a struct ext3_inode_info. In general, the *only* place where well-written, maintainable, kernel code should try to use EXT3_I is inside fs/ext3/*.c. - Ted </blockquote></div> -- Best regards, 张树坤 北京理工大学，计算机科学技术学院 Sucan Computer Department,Beijing Institute of Technology,China