>So you fundamentally reject the prototype it in one fs and then abstract>it to others development model?> >

Hans,after many years here now, one would have thought you would have "got" this part of Linux: kernel development & code that gets into the kernel only does so by getting past the benevolent dictators.instead, it seems that every time there is ReiserFS to be merged (and we can go back in history a number of years here..), it always seems to come as a great shock that your code won't be merged 'as-is' without peer review & comment.

don't feel that you're being singled out here. you aren't. there isn't any anti-Hans-and-his-filesystem conspiracy here.there are plenty of examples on where this has happened in Linux previously in other parts of the tree.EVMS is a great example of similar things - a proposal to include kernel code to do various volume-mgmt functions - which was basically accomplishing the same goal as that of LVM/LVM2 and MD drivers (& DM framework).the EVMS team are a great act to follow - see http://lwn.net/Articles/14714/ - they showed high levels of professional conduct and made what was essentially a 'hard' but 'correct' decision in reworking EVMS to use the same DM infrastructure as LVM2.there are countless other examples at various times - various 'competing' IPv6 projects, IPSec, various "hardware" (software) RAID controllers, various IP offload schemes et al.

why does Reiserfs have to be any different?

you know that VFS is the mechanism in Linux. you know (i hope..) how it works. it isn't so hard to see how many of the Reiser4 "plug-ins" could be tied into VFS calls.OR, if they cannot TODAY, propose how VFS _COULD_ be made to do this.