On Tue, Sep 18, 2012 at 10:24:55AM +0800, Zhi Yong Wu wrote: > On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.kernel@xxxxxxxxx wrote: > >> 20 files changed, 2275 insertions(+), 1 deletions(-) > >> create mode 100644 fs/hot_debugfs.c > >> create mode 100644 fs/hot_debugfs.h > >> create mode 100644 fs/hot_hash.c > >> create mode 100644 fs/hot_hash.h > >> create mode 100644 fs/hot_rb.c > >> create mode 100644 fs/hot_rb.h > >> create mode 100644 fs/hot_track.c > >> create mode 100644 fs/hot_track.h > >> create mode 100644 include/linux/hot_track.h > > > > So, 9 new files for tracking all of this? I'm not sure that so > > many new files are needed - putting it all in fs/hot_tracking.[ch] > > might make more sense, or if all 8 fs/hot* files remain, putting > > them in their own subdirectory might be an idea (like quota). > If all functions are in two files, they will be large and the logic is > not so clear. so i prefer the latter. thanks. A single file is much easier to handle when searching and editting, though. And realistically: $ wc -l fs/*.c |sort -nr -k 1 |head -10 62483 total 4000 fs/namei.c 3281 fs/buffer.c 3169 fs/dcache.c 2677 fs/namespace.c 2364 fs/locks.c 2321 fs/exec.c 2120 fs/binfmt_elf.c 2053 fs/splice.c 1934 fs/eventpoll.c $ There are plenty of files for a single function/subsystem of around the aggregate size of this code, so everyone is used to dealing with this amount of logic for a particular feature in a single file. I much prefer it that way, to tell the truth, because I find it fairly common to have 5-10 files open at once when tracking something through, say, the buffered IO path. If I've now got to have another 5-10 files open just to track that same code path through this index, then that makes it much more difficult to manage than if were all in one .c file. IOWs, splitting code up into multiple files is not a win when the resultant files are all small and interdependent and you need to look at multiple files at the same time to understand what the code does as a whole.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
