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
--

[ message continues ]

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=p...

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
--

[ message continues ]

Hmmm, removing the plugin support might not be so hard....  I might
have to try this... I am not impressed with btrfs yet.
-Ryan

--

[ message continues ]

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
--

[ message continues ]

My most up to date information is that Edward is still actively working 
on reiser4....

ric

--

[ message continues ]

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


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

Well, Ted, I'll promise ;)
We'll adhere strictly the propositional logic in the review thread..

Thanks,


--

[ message continues ]

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
--

[ message continues ]

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


--

[ message continues ]

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
--

[ message continues ]

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,

--

[ message continues ]

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
--

[ message continues ]

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

--

[ message continues ]

"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

--

[ message continues ]