![]() | |||||||||||||
Messages in this thread |
Hans Reiser <reiser@namesys.com> wrote: > > > Andrew asked me to put together a list of things that need to be done > before merging: Thanks. As I said to Hans, if we can get a list of bullet-point actions nailed down and agreed to then we have an uncontroversial path to happiness and a merge. Let's get down and concentrate on technical specifics. Hans, please maintain this list and republish it as we work through things. > * VFS will dispatch directly to the method of the plugin for the > *_operations methods. This requires duplicating to all plugin methods > the common code currently used by all reiser4 plugins for a given > method. It has the desirable side effect of making the methods more > fully self-contained, which is somethng I had wanted two years ago and > was a little sad to not get, and the cost of duplicating some code. > Since not all plugin methods are *_operations, it means we have two > structures with duplicated data, and duplicate data that must be in sync > at all times is classical badness in programming technique (see Codd and > normalization). vs owns this task > > * review all sparse complaints, and revise as appropriate. > > * panic and code beauty: everyone agrees that having function, file, > and line added to reiser4_panic output hurts nothing (I hope). Everyone > agrees that restarting the machine without an error message seems like a > useless option to allow. Much else was argued, not sure if anything > was a consensus view. Various detail improvements were suggested by > Pecca, and I agreed with half of them. > > > * metafiles should be disabled until we can present code that works > right. Half the list thinks we cannot solve the cycles problem ever. > Disable metafiles and postpone problem until working code, or the > failure to produce it, makes it possible to do more than rant at each > other. This is currently already done in the -mm patches, but is > mentioned lest someone think it forgotten. > > * update the locking documentation > There's also the custom list, hash and debug code. We should either a) remove them or b) generify them and submit as standalone works or c) justify them as custom-to-reiser4 and leave them as-is. - 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/ | ||||||||||||
| Last update: 2005-06-28 01:32 [from the cache] ©2003-2008 | |||||||||||||