On Wed, Dec 10, 2008 at 08:11:02PM -0500, Steven Rostedt wrote: > > On Wed, 10 Dec 2008, Mike Frysinger wrote: > > > On Wed, Dec 10, 2008 at 18:43, Al Viro wrote: > > > On Wed, Dec 10, 2008 at 06:37:28PM -0500, Steven Rostedt wrote: > > >> > > >> The following patch is in: > > >> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git > > >> > > >> branch: cleanups > > > > > > Would be better to take init_fs to something in fs/ or kernel/ and kill > > > the duplicates, along with INIT_FS macro itself... > > > > how about the next level: unify init_task.c. a quick check shows that > > like 90% of the stuff in there is the same for everyone ... > > -mike > > I could probably do it for x86 and PPC, but beyond that, each arch > maintainer will have to do it separately. That's a change that would need > testing. > > These changes are trivial (something I need to get RT working). Guys, let's not take it to init/main.c, please. That file is basically a trashcan and I'd rather take that stuff to more or less relevant places in kernel/* and fs/*. FWIW, I've done that with init_files (fs/file.c) some time ago. For init_fs... Hell knows. Might make sense to take that to separate file, actually (kernel/exit.c and kernel/fork.c bits related to fs_struct). BTW, why does sparc64 export put_fs_struct? And is there any good reason for doing copy_fs_struct() in nfsd instead of just teaching kthread_create() how to create threads without sharing fs_struct (or descriptors, while we are at it)? -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
