Why is reiser4 still not in a vanilla kernel for testing. I have had
to apply the reiser4 patches from -mm kernels to vanilla based
patchset for over a year now. Reiser4 works fine, what will it take to
get it included in vanilla? Here is a patch to add reiser4 to
2.6.27-rc1:
http://zen-sources.org/files/reiser4-for-2.6.27-rc1.patch
-Ryan
On Fri, Aug 01, 2008 at 09:49:55AM -0400, Ryan Hope wrote:
> Why is reiser4 still not in a vanilla kernel for testing. I have had
> to apply the reiser4 patches from -mm kernels to vanilla based
> patchset for over a year now. Reiser4 works fine, what will it take to
> get it included in vanilla? Here is a patch to add reiser4 to
> 2.6.27-rc1:
>
> http://zen-sources.org/files/reiser4-for-2.6.27-rc1.patch
The reasons laid out in these web pages haven't changed.
http://kernelnewbies.org/WhyReiser4IsNotIn
http://lkml.org/lkml/2006/7/28/180
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=668645;page=1;sb=post_latest_reply;so=ASC;mh=25;list=linux
Now that Hans is out of the picture, and Namesys seems to have
collapsed, maybe someone can yank out the plugin architecture that
Linus and others have objected to, which as near as I could tell was
part of the Namesys's somewhat dodgy business plan of creating and
selling (possibly proprietary; not sure what license they were going
to be under) plugin modules for Reiser4 to make money. The other
issue that was raised during the review were some locking issues
raised by Al Viro, if memory serves correctly. I'm not sure if they
were ever fixed; at least initially they were brushed aside by Hans.
In the meantime, people who really like reiser4 might want to take a
look at btrfs; it has a number of the same design ideas that reiser3/4
had --- except (a) the filesystem format has support for some advanced
features that are designed to leapfrog ZFS, (b) the maintainer is not
a crazy man and works well with other LKML developers (free hint: if
your code needs to be reviewed to get in, and reviewers are scarce;
don't insult and abuse the volunteer reviewers as Hans did --- Not a
good plan!).
- Ted
Hmmm, removing the plugin support might not be so hard.... I might
have to try this... I am not impressed with btrfs yet.
-Ryan
On Fri, Aug 1, 2008 at 12:25 PM, Theodore Tso <[email protected]> wrote:
> On Fri, Aug 01, 2008 at 09:49:55AM -0400, Ryan Hope wrote:
>> Why is reiser4 still not in a vanilla kernel for testing. I have had
>> to apply the reiser4 patches from -mm kernels to vanilla based
>> patchset for over a year now. Reiser4 works fine, what will it take to
>> get it included in vanilla? Here is a patch to add reiser4 to
>> 2.6.27-rc1:
>>
>> http://zen-sources.org/files/reiser4-for-2.6.27-rc1.patch
>
> The reasons laid out in these web pages haven't changed.
>
> http://kernelnewbies.org/WhyReiser4IsNotIn
> http://lkml.org/lkml/2006/7/28/180
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=668645;page=1;sb=post_latest_reply;so=ASC;mh=25;list=linux
>
> Now that Hans is out of the picture, and Namesys seems to have
> collapsed, maybe someone can yank out the plugin architecture that
> Linus and others have objected to, which as near as I could tell was
> part of the Namesys's somewhat dodgy business plan of creating and
> selling (possibly proprietary; not sure what license they were going
> to be under) plugin modules for Reiser4 to make money. The other
> issue that was raised during the review were some locking issues
> raised by Al Viro, if memory serves correctly. I'm not sure if they
> were ever fixed; at least initially they were brushed aside by Hans.
>
> In the meantime, people who really like reiser4 might want to take a
> look at btrfs; it has a number of the same design ideas that reiser3/4
> had --- except (a) the filesystem format has support for some advanced
> features that are designed to leapfrog ZFS, (b) the maintainer is not
> a crazy man and works well with other LKML developers (free hint: if
> your code needs to be reviewed to get in, and reviewers are scarce;
> don't insult and abuse the volunteer reviewers as Hans did --- Not a
> good plan!).
>
> - Ted
>
On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
> Hmmm, removing the plugin support might not be so hard.... I might
> have to try this... I am not impressed with btrfs yet.
Well, if you're going to work on reiser4 (and I think there were other
people who had also expressed interest/plans to work on it; you might
try doing a search on the various mailing lists so you can coordinate
with them and avoid duplicating work), my suggestion to you would be
to find the comments that were made by the reviewers way back when,
and make sure those comments have been addressed.
Then, re-requests a code review, and promise that you won't abuse, and
insult the integrity and impugn the motivations of the reviewers like
Hans did, and hopefully after they review the code, fix those problems
as well. Then you can try resubmitting for inclusion.
Best regards,
- Ted
Theodore Tso wrote:
> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>
>> Hmmm, removing the plugin support might not be so hard.... I might
>> have to try this... I am not impressed with btrfs yet.
>>
>
> Well, if you're going to work on reiser4 (and I think there were other
> people who had also expressed interest/plans to work on it; you might
> try doing a search on the various mailing lists so you can coordinate
> with them and avoid duplicating work), my suggestion to you would be
> to find the comments that were made by the reviewers way back when,
> and make sure those comments have been addressed.
>
> Then, re-requests a code review, and promise that you won't abuse, and
> insult the integrity and impugn the motivations of the reviewers like
> Hans did, and hopefully after they review the code, fix those problems
> as well. Then you can try resubmitting for inclusion.
>
> Best regards,
>
> - Ted
>
My most up to date information is that Edward is still actively working
on reiser4....
ric
Ric Wheeler wrote:
> Theodore Tso wrote:
>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>
Hi, I am here :)
Join our mailing list:
http://vger.kernel.org/vger-lists.html#reiserfs-devel
http://marc.info/?l=reiserfs-devel&r=1&w=2
There are many interesting tasks to resolve/investigate..
>>> Hmmm, removing the plugin support might not be so hard.... I might
>>> have to try this...
Please, don't try to do this.
I am working on the plugin design document. It will be ready
approximately in September. I believe that it'll address all the
mentioned complaints.
>>> I am not impressed with btrfs yet.
>>>
>>
>> Well, if you're going to work on reiser4 (and I think there were other
>> people who had also expressed interest/plans to work on it; you might
>> try doing a search on the various mailing lists so you can coordinate
>> with them and avoid duplicating work), my suggestion to you would be
>> to find the comments that were made by the reviewers way back when,
>> and make sure those comments have been addressed.
>>
>> Then, re-requests a code review, and promise that you won't abuse, and
>> insult the integrity and impugn the motivations of the reviewers
Well, Ted, I'll promise ;)
We'll adhere strictly the propositional logic in the review thread..
Thanks,
Edward.
>> like
>> Hans did, and hopefully after they review the code, fix those problems
>> as well. Then you can try resubmitting for inclusion.
>>
>> Best regards,
>>
>> - Ted
>>
>
> My most up to date information is that Edward is still actively
> working on reiser4....
>
> ric
>
>
On Fri, Aug 01, 2008 at 12:25:48PM -0400, Theodore Tso wrote:
> On Fri, Aug 01, 2008 at 09:49:55AM -0400, Ryan Hope wrote:
> > Why is reiser4 still not in a vanilla kernel for testing. I have had
> > to apply the reiser4 patches from -mm kernels to vanilla based
> > patchset for over a year now. Reiser4 works fine, what will it take to
> > get it included in vanilla? Here is a patch to add reiser4 to
> > 2.6.27-rc1:
> >
> > http://zen-sources.org/files/reiser4-for-2.6.27-rc1.patch
>
> The reasons laid out in these web pages haven't changed.
>
> http://kernelnewbies.org/WhyReiser4IsNotIn
> http://lkml.org/lkml/2006/7/28/180
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=668645;page=1;sb=post_latest_reply;so=ASC;mh=25;list=linux
>
> Now that Hans is out of the picture, and Namesys seems to have
> collapsed, maybe someone can yank out the plugin architecture that
> Linus and others have objected to, which as near as I could tell was
> part of the Namesys's somewhat dodgy business plan of creating and
> selling (possibly proprietary; not sure what license they were going
> to be under) plugin modules for Reiser4 to make money. The other
> issue that was raised during the review were some locking issues
> raised by Al Viro, if memory serves correctly. I'm not sure if they
> were ever fixed;
"That because the real plugins are long gone. It's just that neither the
complainers nor the fanboys in this thread ever read the code or generally
had any clue of their own."
--hch, 1 Aug 2006
Can you explain a little more what this "plugin design documentation"
actually is and how it supposed to help?
-Ryan
On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
<[email protected]> wrote:
> Ric Wheeler wrote:
>> Theodore Tso wrote:
>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>
>
> Hi, I am here :)
> Join our mailing list:
>
> http://vger.kernel.org/vger-lists.html#reiserfs-devel
> http://marc.info/?l=reiserfs-devel&r=1&w=2
>
> There are many interesting tasks to resolve/investigate..
>
>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>> have to try this...
>
> Please, don't try to do this.
>
> I am working on the plugin design document. It will be ready
> approximately in September. I believe that it'll address all the
> mentioned complaints.
>
>>>> I am not impressed with btrfs yet.
>>>>
>>>
>>> Well, if you're going to work on reiser4 (and I think there were other
>>> people who had also expressed interest/plans to work on it; you might
>>> try doing a search on the various mailing lists so you can coordinate
>>> with them and avoid duplicating work), my suggestion to you would be
>>> to find the comments that were made by the reviewers way back when,
>>> and make sure those comments have been addressed.
>>>
>>> Then, re-requests a code review, and promise that you won't abuse, and
>>> insult the integrity and impugn the motivations of the reviewers
>
> Well, Ted, I'll promise ;)
> We'll adhere strictly the propositional logic in the review thread..
>
> Thanks,
> Edward.
>
>>> like
>>> Hans did, and hopefully after they review the code, fix those problems
>>> as well. Then you can try resubmitting for inclusion.
>>>
>>> Best regards,
>>>
>>> - Ted
>>>
>>
>> My most up to date information is that Edward is still actively
>> working on reiser4....
>>
>> ric
>>
>>
>
>
>
Ryan Hope wrote:
> Can you explain a little more what this "plugin design documentation"
> actually is and how it supposed to help?
> -Ryan
>
>
This document is to define plugins, etc primitives (like conversion
of run-time objects) used in reiser4, and to describe all reiser4
interfaces, so that it will be clear that VFS functionality is not
duplicated, there are not VFS layers inside reiser4, etc. (many items
are devoted to interaction between VFS and reiser4).
I am sorry, but these concepts (which are very central) have not been
worked out carefully enough at the moment of this 3-year-old review:
http://kerneltrap.org/node/5330
Edward.
> On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
> <[email protected]> wrote:
>
>> Ric Wheeler wrote:
>>
>>> Theodore Tso wrote:
>>>
>>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>>
>>>>
>> Hi, I am here :)
>> Join our mailing list:
>>
>> http://vger.kernel.org/vger-lists.html#reiserfs-devel
>> http://marc.info/?l=reiserfs-devel&r=1&w=2
>>
>> There are many interesting tasks to resolve/investigate..
>>
>>
>>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>>> have to try this...
>>>>>
>> Please, don't try to do this.
>>
>> I am working on the plugin design document. It will be ready
>> approximately in September. I believe that it'll address all the
>> mentioned complaints.
>>
>>
>>>>> I am not impressed with btrfs yet.
>>>>>
>>>>>
>>>> Well, if you're going to work on reiser4 (and I think there were other
>>>> people who had also expressed interest/plans to work on it; you might
>>>> try doing a search on the various mailing lists so you can coordinate
>>>> with them and avoid duplicating work), my suggestion to you would be
>>>> to find the comments that were made by the reviewers way back when,
>>>> and make sure those comments have been addressed.
>>>>
>>>> Then, re-requests a code review, and promise that you won't abuse, and
>>>> insult the integrity and impugn the motivations of the reviewers
>>>>
>> Well, Ted, I'll promise ;)
>> We'll adhere strictly the propositional logic in the review thread..
>>
>> Thanks,
>> Edward.
>>
>>
>>>> like
>>>> Hans did, and hopefully after they review the code, fix those problems
>>>> as well. Then you can try resubmitting for inclusion.
>>>>
>>>> Best regards,
>>>>
>>>> - Ted
>>>>
>>>>
>>> My most up to date information is that Edward is still actively
>>> working on reiser4....
>>>
>>> ric
>>>
>>>
>>>
>>
>>
>
>
So the purpose of that "plugins" document is just to "defend" the
present state of the reiser4 code?
On Sat, Aug 2, 2008 at 6:56 PM, Edward Shishkin
<[email protected]> wrote:
> Ryan Hope wrote:
>> Can you explain a little more what this "plugin design documentation"
>> actually is and how it supposed to help?
>> -Ryan
>>
>>
>
> This document is to define plugins, etc primitives (like conversion
> of run-time objects) used in reiser4, and to describe all reiser4
> interfaces, so that it will be clear that VFS functionality is not
> duplicated, there are not VFS layers inside reiser4, etc. (many items
> are devoted to interaction between VFS and reiser4).
> I am sorry, but these concepts (which are very central) have not been
> worked out carefully enough at the moment of this 3-year-old review:
> http://kerneltrap.org/node/5330
>
> Edward.
>
>> On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
>> <[email protected]> wrote:
>>
>>> Ric Wheeler wrote:
>>>
>>>> Theodore Tso wrote:
>>>>
>>>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>>>
>>>>>
>>> Hi, I am here :)
>>> Join our mailing list:
>>>
>>> http://vger.kernel.org/vger-lists.html#reiserfs-devel
>>> http://marc.info/?l=reiserfs-devel&r=1&w=2
>>>
>>> There are many interesting tasks to resolve/investigate..
>>>
>>>
>>>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>>>> have to try this...
>>>>>>
>>> Please, don't try to do this.
>>>
>>> I am working on the plugin design document. It will be ready
>>> approximately in September. I believe that it'll address all the
>>> mentioned complaints.
>>>
>>>
>>>>>> I am not impressed with btrfs yet.
>>>>>>
>>>>>>
>>>>> Well, if you're going to work on reiser4 (and I think there were other
>>>>> people who had also expressed interest/plans to work on it; you might
>>>>> try doing a search on the various mailing lists so you can coordinate
>>>>> with them and avoid duplicating work), my suggestion to you would be
>>>>> to find the comments that were made by the reviewers way back when,
>>>>> and make sure those comments have been addressed.
>>>>>
>>>>> Then, re-requests a code review, and promise that you won't abuse, and
>>>>> insult the integrity and impugn the motivations of the reviewers
>>>>>
>>> Well, Ted, I'll promise ;)
>>> We'll adhere strictly the propositional logic in the review thread..
>>>
>>> Thanks,
>>> Edward.
>>>
>>>
>>>>> like
>>>>> Hans did, and hopefully after they review the code, fix those problems
>>>>> as well. Then you can try resubmitting for inclusion.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> - Ted
>>>>>
>>>>>
>>>> My most up to date information is that Edward is still actively
>>>> working on reiser4....
>>>>
>>>> ric
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Ryan Hope wrote:
> So the purpose of that "plugins" document is just to "defend" the
> present state of the reiser4 code?
>
Yes. In particular.
Plugins stuff is a way of data storage optimization and its
removing definitely would be a mistake. What can arise here
again is complaints about "layering violation". However,
addressing them doesn't necessarily mean removing the whole
plugin stuff. I hope that this document will help such discussions
to be more constructive.
Thanks,
Edward.
> On Sat, Aug 2, 2008 at 6:56 PM, Edward Shishkin
> <[email protected]> wrote:
>
>> Ryan Hope wrote:
>>
>>> Can you explain a little more what this "plugin design documentation"
>>> actually is and how it supposed to help?
>>> -Ryan
>>>
>>>
>>>
>> This document is to define plugins, etc primitives (like conversion
>> of run-time objects) used in reiser4, and to describe all reiser4
>> interfaces, so that it will be clear that VFS functionality is not
>> duplicated, there are not VFS layers inside reiser4, etc. (many items
>> are devoted to interaction between VFS and reiser4).
>> I am sorry, but these concepts (which are very central) have not been
>> worked out carefully enough at the moment of this 3-year-old review:
>> http://kerneltrap.org/node/5330
>>
>> Edward.
>>
>>
>>> On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
>>> <[email protected]> wrote:
>>>
>>>
>>>> Ric Wheeler wrote:
>>>>
>>>>
>>>>> Theodore Tso wrote:
>>>>>
>>>>>
>>>>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>>>>
>>>>>>
>>>>>>
>>>> Hi, I am here :)
>>>> Join our mailing list:
>>>>
>>>> http://vger.kernel.org/vger-lists.html#reiserfs-devel
>>>> http://marc.info/?l=reiserfs-devel&r=1&w=2
>>>>
>>>> There are many interesting tasks to resolve/investigate..
>>>>
>>>>
>>>>
>>>>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>>>>> have to try this...
>>>>>>>
>>>>>>>
>>>> Please, don't try to do this.
>>>>
>>>> I am working on the plugin design document. It will be ready
>>>> approximately in September. I believe that it'll address all the
>>>> mentioned complaints.
>>>>
>>>>
>>>>
>>>>>>> I am not impressed with btrfs yet.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Well, if you're going to work on reiser4 (and I think there were other
>>>>>> people who had also expressed interest/plans to work on it; you might
>>>>>> try doing a search on the various mailing lists so you can coordinate
>>>>>> with them and avoid duplicating work), my suggestion to you would be
>>>>>> to find the comments that were made by the reviewers way back when,
>>>>>> and make sure those comments have been addressed.
>>>>>>
>>>>>> Then, re-requests a code review, and promise that you won't abuse, and
>>>>>> insult the integrity and impugn the motivations of the reviewers
>>>>>>
>>>>>>
>>>> Well, Ted, I'll promise ;)
>>>> We'll adhere strictly the propositional logic in the review thread..
>>>>
>>>> Thanks,
>>>> Edward.
>>>>
>>>>
>>>>
>>>>>> like
>>>>>> Hans did, and hopefully after they review the code, fix those problems
>>>>>> as well. Then you can try resubmitting for inclusion.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> - Ted
>>>>>>
>>>>>>
>>>>>>
>>>>> My most up to date information is that Edward is still actively
>>>>> working on reiser4....
>>>>>
>>>>> ric
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Well as I remember akpm and hch both said that these "plugins" are
just a way of modular programing, and not layering violation, but I
just can't find those mails now, there were a lot of them.
On Mon, Aug 4, 2008 at 1:11 PM, Edward Shishkin
<[email protected]> wrote:
> Ryan Hope wrote:
>> So the purpose of that "plugins" document is just to "defend" the
>> present state of the reiser4 code?
>>
>
> Yes. In particular.
>
> Plugins stuff is a way of data storage optimization and its
> removing definitely would be a mistake. What can arise here
> again is complaints about "layering violation". However,
> addressing them doesn't necessarily mean removing the whole
> plugin stuff. I hope that this document will help such discussions
> to be more constructive.
>
> Thanks,
> Edward.
>
>> On Sat, Aug 2, 2008 at 6:56 PM, Edward Shishkin
>> <[email protected]> wrote:
>>
>>> Ryan Hope wrote:
>>>
>>>> Can you explain a little more what this "plugin design documentation"
>>>> actually is and how it supposed to help?
>>>> -Ryan
>>>>
>>>>
>>>>
>>> This document is to define plugins, etc primitives (like conversion
>>> of run-time objects) used in reiser4, and to describe all reiser4
>>> interfaces, so that it will be clear that VFS functionality is not
>>> duplicated, there are not VFS layers inside reiser4, etc. (many items
>>> are devoted to interaction between VFS and reiser4).
>>> I am sorry, but these concepts (which are very central) have not been
>>> worked out carefully enough at the moment of this 3-year-old review:
>>> http://kerneltrap.org/node/5330
>>>
>>> Edward.
>>>
>>>
>>>> On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>> Ric Wheeler wrote:
>>>>>
>>>>>
>>>>>> Theodore Tso wrote:
>>>>>>
>>>>>>
>>>>>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Hi, I am here :)
>>>>> Join our mailing list:
>>>>>
>>>>> http://vger.kernel.org/vger-lists.html#reiserfs-devel
>>>>> http://marc.info/?l=reiserfs-devel&r=1&w=2
>>>>>
>>>>> There are many interesting tasks to resolve/investigate..
>>>>>
>>>>>
>>>>>
>>>>>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>>>>>> have to try this...
>>>>>>>>
>>>>>>>>
>>>>> Please, don't try to do this.
>>>>>
>>>>> I am working on the plugin design document. It will be ready
>>>>> approximately in September. I believe that it'll address all the
>>>>> mentioned complaints.
>>>>>
>>>>>
>>>>>
>>>>>>>> I am not impressed with btrfs yet.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Well, if you're going to work on reiser4 (and I think there were other
>>>>>>> people who had also expressed interest/plans to work on it; you might
>>>>>>> try doing a search on the various mailing lists so you can coordinate
>>>>>>> with them and avoid duplicating work), my suggestion to you would be
>>>>>>> to find the comments that were made by the reviewers way back when,
>>>>>>> and make sure those comments have been addressed.
>>>>>>>
>>>>>>> Then, re-requests a code review, and promise that you won't abuse, and
>>>>>>> insult the integrity and impugn the motivations of the reviewers
>>>>>>>
>>>>>>>
>>>>> Well, Ted, I'll promise ;)
>>>>> We'll adhere strictly the propositional logic in the review thread..
>>>>>
>>>>> Thanks,
>>>>> Edward.
>>>>>
>>>>>
>>>>>
>>>>>>> like
>>>>>>> Hans did, and hopefully after they review the code, fix those problems
>>>>>>> as well. Then you can try resubmitting for inclusion.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> - Ted
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> My most up to date information is that Edward is still actively
>>>>>> working on reiser4....
>>>>>>
>>>>>> ric
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Found it :)
akpm:
"The plugins appear to be wildly misnamed - they're just an internal
abstraction layer which permits later feature additions to be added in a
clean and safe manner. Certainly not worth all this fuss."
http://marc.info/?l=linux-kernel&m=115442117418736&w=2
hch:
"That because the real plugins are long gone. It's just that neither the
complainers nor the fanboys in this thread ever read the code or generally
had any clue of their own."
http://marc.info/?l=linux-kernel&m=115443267908751&w=2
Hope this is of some help.
Bye
Dushan
On Mon, Aug 4, 2008 at 1:18 PM, Dushan Tcholich <[email protected]> wrote:
> Well as I remember akpm and hch both said that these "plugins" are
> just a way of modular programing, and not layering violation, but I
> just can't find those mails now, there were a lot of them.
>
>
> On Mon, Aug 4, 2008 at 1:11 PM, Edward Shishkin
> <[email protected]> wrote:
>> Ryan Hope wrote:
>>> So the purpose of that "plugins" document is just to "defend" the
>>> present state of the reiser4 code?
>>>
>>
>> Yes. In particular.
>>
>> Plugins stuff is a way of data storage optimization and its
>> removing definitely would be a mistake. What can arise here
>> again is complaints about "layering violation". However,
>> addressing them doesn't necessarily mean removing the whole
>> plugin stuff. I hope that this document will help such discussions
>> to be more constructive.
>>
>> Thanks,
>> Edward.
>>
>>> On Sat, Aug 2, 2008 at 6:56 PM, Edward Shishkin
>>> <[email protected]> wrote:
>>>
>>>> Ryan Hope wrote:
>>>>
>>>>> Can you explain a little more what this "plugin design documentation"
>>>>> actually is and how it supposed to help?
>>>>> -Ryan
>>>>>
>>>>>
>>>>>
>>>> This document is to define plugins, etc primitives (like conversion
>>>> of run-time objects) used in reiser4, and to describe all reiser4
>>>> interfaces, so that it will be clear that VFS functionality is not
>>>> duplicated, there are not VFS layers inside reiser4, etc. (many items
>>>> are devoted to interaction between VFS and reiser4).
>>>> I am sorry, but these concepts (which are very central) have not been
>>>> worked out carefully enough at the moment of this 3-year-old review:
>>>> http://kerneltrap.org/node/5330
>>>>
>>>> Edward.
>>>>
>>>>
>>>>> On Fri, Aug 1, 2008 at 6:40 PM, Edward Shishkin
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>> Ric Wheeler wrote:
>>>>>>
>>>>>>
>>>>>>> Theodore Tso wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Fri, Aug 01, 2008 at 12:34:53PM -0400, Ryan Hope wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> Hi, I am here :)
>>>>>> Join our mailing list:
>>>>>>
>>>>>> http://vger.kernel.org/vger-lists.html#reiserfs-devel
>>>>>> http://marc.info/?l=reiserfs-devel&r=1&w=2
>>>>>>
>>>>>> There are many interesting tasks to resolve/investigate..
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> Hmmm, removing the plugin support might not be so hard.... I might
>>>>>>>>> have to try this...
>>>>>>>>>
>>>>>>>>>
>>>>>> Please, don't try to do this.
>>>>>>
>>>>>> I am working on the plugin design document. It will be ready
>>>>>> approximately in September. I believe that it'll address all the
>>>>>> mentioned complaints.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> I am not impressed with btrfs yet.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Well, if you're going to work on reiser4 (and I think there were other
>>>>>>>> people who had also expressed interest/plans to work on it; you might
>>>>>>>> try doing a search on the various mailing lists so you can coordinate
>>>>>>>> with them and avoid duplicating work), my suggestion to you would be
>>>>>>>> to find the comments that were made by the reviewers way back when,
>>>>>>>> and make sure those comments have been addressed.
>>>>>>>>
>>>>>>>> Then, re-requests a code review, and promise that you won't abuse, and
>>>>>>>> insult the integrity and impugn the motivations of the reviewers
>>>>>>>>
>>>>>>>>
>>>>>> Well, Ted, I'll promise ;)
>>>>>> We'll adhere strictly the propositional logic in the review thread..
>>>>>>
>>>>>> Thanks,
>>>>>> Edward.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> like
>>>>>>>> Hans did, and hopefully after they review the code, fix those problems
>>>>>>>> as well. Then you can try resubmitting for inclusion.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> - Ted
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> My most up to date information is that Edward is still actively
>>>>>>> working on reiser4....
>>>>>>>
>>>>>>> ric
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>