On Thu, 1 May 2008, Al Viro wrote:

quoted text
> FWIW, after the last month's flamefests I decided to actually do something
> about review density of code in the areas I'm theoretically responsible
> for.  Namely, do systematic review of core data structure handling (starting
> with the place where most of the codepaths get into VFS - descriptor tables
> and struct file), doing both blow-by-blow writeup on how that sort of things
> is done and documentation of the life cycle/locking rules/assertions made
> by code/etc.  I made one bad mistake that held the things back for quite
> a while - sending heads-up for one of the worse bugs found in process to
> never-sufficiently-damned vendor-sec.  The last time I'm doing that, TYVM...
>
> Anyway, I'm going to get the notes on that stuff in order and put them in
> the open.  I really hope that other folks will join the fun afterwards.
> The goal is to get a coherent braindump that would be sufficient for
> people new to the area wanting to understand and review VFS-related code -
> both in the tree and in new patches.

thank you, the lack of good documentation on the intent of the code has 
been a significant barrier for new people. it's (relativly) easy for a 
good programmer to look at the code and figure out how it does things, a 
bit harder to figure out what it does, but why it does it (and what it was 
actually _intended_ to do) is very hard to track down

quoted text
> files_struct/fdtable handling is mostly dealt with, struct file is only
> partially done - unfortunately, struct file_lock has to be dealt with
> before that and it's a (predictable) nightmare.  On the other end of
> things, fs_struct is not really started, vfsmount review is partially
> done, dentry/superblock/inode not even touched.
>
> Even with what little had been covered... well, let's just say that it
> caught quite a few fun turds.  With typical age around 3-4 years.  And
> VFS is not the messiest part of the tree...

it may not be the messiest part of the tree, but it's definantly one of 
the hardest to figure out the intent of.

David Lang
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/