Messages in this thread | | | Date | Tue, 28 Jun 2005 22:41:35 -0700 | From | Hans Reiser <> | Subject | Re: reiser4 merging action list |
| |
Andrew Morton wrote:
>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. > > > > > > either b) or c) is ok with me for the list code. The debug code should be c) I think.
Probably vs can offer a more detailed and accurate opinion,
Hans - 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/
| |