Andrew Morton wrote:
>Hans Reiser <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
