Re: [2.6] Most likely to be merged by Halloween... THE LIST]

[Marcin Dalecki <dalecki@evision.ag>]

Hans Reiser wrote:
> Rik van Riel wrote:
> 
>> On Sat, 20 Jul 2002, Hans Reiser wrote:
>>
>>  
>>
>>> What I was advocating was a schedule of:
>>> 1) feature submission deadline
>>> 2) period of working through feature backlog
>>> 3) feature acceptance ending date
>>>   
>>
>>
>> So, what feature are you trying to smuggle into the kernel
>> but are afraid isn't ready on time and why do you think it
>> couldn't be backported into 2.6 later, when 2.6 is stable ?
>>
> Ouch.  He sees right though me.;)
> 
> The core Reiser4 code should be in time.  Reiser4 will have its core 
> code stable in a month I hope, and by core code I mean code that does 
> what V3 does but on top of a plugin infrastructure and faster than V3 in 
> at least some measures. 
> What I am worried about schedule-wise are:
> 
> * the API for exporting transactions to user space (the in kernel buffer 
> management code to support it is completed but the API is not yet done). 
> Uses the new system call we are adding.
> 
> * The traditional file API is designed for efficiency of repeated 
> operations to the same file.  As part of our effort to make files able 
> to do everything that extended attributes can do, but more flexibly, we 
> are creating a new system call.  This new system call can perform 
> multiple operations on files in one system call, and is very convenient 
> for a bunch of small IOs to different files.
> 
> * file inheritance
> 
> Some other reiser4 things won't make it, but they seem like they should 
> be easier to get in later because they are plugins:
> 
> * encryption plugin
> 
> * ACL plugin
> 
> * audit plugin

I strongly oppose OSes with mutating semantics and don't like the
"plugin" idea at all therefore.