The reiser4 programming style is recursive?

The reiser4 programming style is recursive?

[Ralph Ulrich]

Is it true that the programming style of reiser4 is recursive style and
that this kind of style was rejected from the kernel developers?

If  true: How much effort would it be to recode reiser4 to a style which
has a chance of inclusion in the linux kernel?

And if there will be a recoding effort to be made, wouldn't it be a
great idea to use a cleaner and more modern programming language link D ?

Thanks in advance for answering my more general questions.
Ralph

Re: The reiser4 programming style is recursive?

[Teran McKinney]

Of course, D would be a great choice, but C# may be better. I hear
that Torvalds really wants to see more Mono drivers in the kernel.
What else would we do with our 4GB RAM machines?

No seriously, nothing in the kernel is coded in anything but C or
assembler. You might as well just make the C code a little more
pretty.

--Teran

On Wed, Dec 10, 2008 at 21:34, Ralph Ulrich <eulenreich@gmx.de> wrote:
> Is it true that the programming style of reiser4 is recursive style and
> that this kind of style was rejected from the kernel developers?
>
> If  true: How much effort would it be to recode reiser4 to a style which
> has a chance of inclusion in the linux kernel?
>
> And if there will be a recoding effort to be made, wouldn't it be a
> great idea to use a cleaner and more modern programming language link D ?
>
> Thanks in advance for answering my more general questions.
> Ralph
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: The reiser4 programming style is recursive?

[Ralph Ulrich]

Teran McKinney schrieb:
> Of course, D would be a great choice, but C# may be better. I hear
> that Torvalds really wants to see more Mono drivers in the kernel.
> What else would we do with our 4GB RAM machines?
There is even a Ms project for that :-)
> 
> No seriously, nothing in the kernel is coded in anything but C or
> assembler. You might as well just make the C code a little more
> pretty.
But you know that D is meant for drivers - as a C++ replacement!?

You didn' answer my main question:
>> Is it true that the programming style of reiser4 is recursive style and
>> that this kind of style was rejected from the kernel developers?

Greeting from rainy Hamburg,
Ralph

Re: The reiser4 programming style is recursive?

[David Backeberg]

On Wed, Dec 10, 2008 at 5:07 PM, Ralph Ulrich <eulenreich@gmx.de> wrote:
> You didn' answer my main question:
>>> Is it true that the programming style of reiser4 is recursive style and

The code is open, and you're welcome to read it. I wouldn't call
recursion a "style" so much as an approach to solving a particular
problem. I think of "style" being things like whether your curly
braces go on the same line or on the next line, how much whitespace
you allow between code elements, etc. Perhaps you're just saying that
because English isn't your primary language?

>>> that this kind of style was rejected from the kernel developers?

Which rejection? And who are "kernel developers"?

The code is in Andrew Morton's tree, and I think "kernel developers"
would agree that Andrew Morton is a kernel developer.

If your actual question is "how come reiser4 is not in mainline?"

This question has been asked and answered repeatedly. In fact, try
typing "reiser4 mainline" into google and read the results.

Re: The reiser4 programming style is recursive?

[Ralph Ulrich]

David Backeberg schrieb:
>> >> Is it true that the programming style of reiser4 is recursive
style and
> >
> > I wouldn't call
> > recursion a "style" so much as an approach to solving a particular
> > problem. I think of "style" being things like whether your curly
> > braces go on the same line or on the next line, how much whitespace
> > you allow between code elements, etc. Perhaps you're just saying that
> > because English isn't your primary language?
Yes , i am german...
But curly braces i would subsumize under "coding style".
In german language the wording "programming" (programmieren)
means looking for the ways of logic, managing the ways
the streams of data go ... etc.

I watched some video of a linux convention. And there a guru
(do not know the name anymore, some weeks ago) mentioned that
programming recursive in the kernel is a absolute no go, every
recursion can also be programmed without. And that is often even
faster. Something like that he said. And for my understandings this
was said against reiser4 even if it was not mentioned.

Ralph
Post Scriptum: As I know recursiveness has more beauty for
programmers like Hans Reiser

Re: The reiser4 programming style is recursive?

[Toby Thain]

On 10-Dec-08, at 5:07 PM, Ralph Ulrich wrote:

> Teran McKinney schrieb:
>> Of course, D would be a great choice, but C# may be better. I hear
>> that Torvalds really wants to see more Mono drivers in the kernel.
>> What else would we do with our 4GB RAM machines?
> There is even a Ms project for that :-)
>>
>> No seriously, nothing in the kernel is coded in anything but C or
>> assembler. You might as well just make the C code a little more
>> pretty.
> But you know that D is meant for drivers - as a C++ replacement!?

Define 'driver'!

C++ has nothing to do with the Linux kernel (and nor does D). The  
kernel and its subsystems will continue to be written in C for the  
fore-C-able future.


>
> You didn' answer my main question:
>>> Is it true that the programming style of reiser4 is recursive  
>>> style and
>>> that this kind of style was rejected from the kernel developers?
>
As for 'recursion', it is nothing to be afraid of. Except the kind  
that blows stacks. ;-)

--Toby


> Greeting from rainy Hamburg,
> Ralph
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs- 
> devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: The reiser4 programming style is recursive?

[Edward Shishkin]

Ralph Ulrich wrote:
> Is it true that the programming style of reiser4 is recursive style

what is a definition of recursive programming style?

>  and
> that this kind of style was rejected from the kernel developers?
>   

AFAIK they were unhappy with assertions and "coding nits"  like
if (foo) {
        bar();
}
Eventually akpm said that assertions are okay and guys send
cleanup patches against other issues once in a while.

> If  true: How much effort would it be to recode reiser4 to a style which
> has a chance of inclusion in the linux kernel?
>
> And if there will be a recoding effort to be made, wouldn't it be a
> great idea to use a cleaner and more modern programming language link D ?
>
> Thanks in advance for answering my more general questions.
> Ralph
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: The reiser4 programming style is recursive?

[Ralph Ulrich]

Edward Shishkin schrieb:
> AFAIK they were unhappy with assertions and "coding nits"  like
> if (foo) {         bar(); }
....
> Eventually akpm said that assertions are okay and guys send
> cleanup patches against other issues once in a while.

And what are Your plans to get reiser4 in the kernel now!

As of now it seems that brtfs,
which has nearly the same "hardware" logic as reiser4
but lacks the whole ground breaking philosophy,
will get there first!

Edward, we are all waiting, what do you need for help?

Ralph

Re: The reiser4 programming style is recursive?

[Edward Shishkin]

Ralph Ulrich wrote:
> Edward Shishkin schrieb:
>   
>> AFAIK they were unhappy with assertions and "coding nits"  like
>> if (foo) {         bar(); }
>>     
> ....
>   
>> Eventually akpm said that assertions are okay and guys send
>> cleanup patches against other issues once in a while.
>>     
>
> And what are Your plans to get reiser4 in the kernel now!
>   

I wouldn't force the events:
there is no hurry, business plans, timelines, etc..

> As of now it seems that brtfs,
> which has nearly the same "hardware" logic as reiser4
> but lacks the whole ground breaking philosophy,
> will get there first!
>   

And what? I don't see any problems if someone gets it prior
to reiser4.

> Edward, we are all waiting, what do you need for help?
>   

To maintain at least one reiser4 subsystem would be real help..
However, it requires a victim in the person of some student(s),
who is ready to kill the best years by sitting in front of monitor
and studying reiser4 sources..
Do you know such ones? ;)

Edward.

Re: The reiser4 programming style is recursive?

[Ralph Ulrich]

Edward Shishkin wrote:
>> will get there first!
> And what? I don't see any problems if someone gets it prior
> to reiser4.
> 
>> Edward, we are all waiting, what do you need for help?
> To maintain at least one reiser4 subsystem would be real help..
> However, it requires a victim in the person of some student(s),
> who is ready to kill the best years by sitting in front of monitor
> and studying reiser4 sources..

Upto recently I had a gentoo linux with your patches running on reiser4
without problems (but with gentoo.org politics at the moment).

Edward, what do you mean "reiser4 subsystem",
"studying reiser4 sources" - debugging?

Ralph

Re: The reiser4 programming style is recursive?

[Edward Shishkin]

Ralph Ulrich wrote:
> Edward Shishkin wrote:
>   
>>> will get there first!
>>>       
>> And what? I don't see any problems if someone gets it prior
>> to reiser4.
>>
>>     
>>> Edward, we are all waiting, what do you need for help?
>>>       
>> To maintain at least one reiser4 subsystem would be real help..
>> However, it requires a victim in the person of some student(s),
>> who is ready to kill the best years by sitting in front of monitor
>> and studying reiser4 sources..
>>     
>
> Upto recently I had a gentoo linux with your patches running on reiser4
> without problems (but with gentoo.org politics at the moment).
>
> Edward, what do you mean "reiser4 subsystem",
>   
examples of subsystems:

in kernel:
. transaction manager;
. flush manager;
. tree operations (balancing);
. unix file plugin;

in user-space:
. libaal and reiser4progs

> "studying reiser4 sources" - debugging?
>   
Currently there is nothing to debug, at least for beginners.

The best way is to start with writing something useful, say
xattrs support, or (meta)data checksums support.

Edward.

Re: The reiser4 programming style is recursive?

[Ralph]

Edward Shishkin wrote:
>>> To maintain at least one reiser4 subsystem would be real help..
>>> However, it requires a victim in the person of some student(s),
>>> who is ready to kill the best years by sitting in front of monitor
>>> and studying reiser4 sources..
>> Edward, what do you mean "reiser4 subsystem",
> examples of subsystems:
> 
> in kernel:
> . transaction manager;
> . flush manager;
> . tree operations (balancing);
> . unix file plugin;
> 
> in user-space:
> . libaal and reiser4progs

I think the user-space libaal and reiser4progs are no problem, everybody who uses your reiser4 patches runs that....

I had a look at your reiser4 patches, and it is clear to me - as the patches
interfere just a handful of lines with the rest of the linux kernel - there is no reiser4 transaction manager in place with just the patches, right ?

Why not creating an experimental vbox real-reiser4-linux image, which everyone interested can get per torrent at mininova ?

I know transaction capability of reiser4 was announced on namesys.com at that time. And the right balancing code in place would have effects like optimizing access on hard disk, right?

> The best way is to start with writing something useful, say
> xattrs support, or (meta)data checksums support.

I read about the xattr problem, traditional linux xattr is to big to suit in place. This means you have to apply the reiser4-philosophy: A file can
have sub files (is not only a file but also a directory of subfiles). Why not creating a new reiser4 specific file type just for xattr. This filetype will be ignored by vfs-api invoked commands except for xattr specific commands.
Such a filetype would be implemented via a new file plugin, i guess, right ?

Ralph

Re: The reiser4 programming style is recursive?

[Edward Shishkin]

Ralph wrote:
> Edward Shishkin wrote:
>   
>>>> To maintain at least one reiser4 subsystem would be real help..
>>>> However, it requires a victim in the person of some student(s),
>>>> who is ready to kill the best years by sitting in front of monitor
>>>> and studying reiser4 sources..
>>>>         
>>> Edward, what do you mean "reiser4 subsystem",
>>>       
>> examples of subsystems:
>>
>> in kernel:
>> . transaction manager;
>> . flush manager;
>> . tree operations (balancing);
>> . unix file plugin;
>>
>> in user-space:
>> . libaal and reiser4progs
>>     
>
> I think the user-space libaal and reiser4progs are no problem,

once, you implement xattrs, checksums, etc., it'll become
a problem immediately, as fsck must know about them..

>  everybody who uses your reiser4 patches runs that....
>
> I had a look at your reiser4 patches, and it is clear to me - as the patches
> interfere just a handful of lines with the rest of the linux kernel - there is no reiser4 transaction manager in place with just the patches, right ?
>   

Its code can be found in reiser4/txnmgr.c

> Why not creating an experimental vbox real-reiser4-linux image, which everyone interested can get per torrent at mininova ?
>
> I know transaction capability of reiser4 was announced on namesys.com at that time.

yes

>  And the right balancing code in place would have effects like optimizing access on hard disk, right?
>
>   
 yes

>   
>> The best way is to start with writing something useful, say
>> xattrs support, or (meta)data checksums support.
>>     
>
> I read about the xattr problem, traditional linux xattr is to big to suit in place. This means you have to apply the reiser4-philosophy: A file can
> have sub files (is not only a file but also a directory of subfiles). Why not creating a new reiser4 specific file type just for xattr.

Subfiles are impossible because of a problem on vfs level
related to hardlink functionality. It seems not yet resolved...

>  This filetype will be ignored by vfs-api invoked commands except for xattr specific commands.
> Such a filetype would be implemented via a new file plugin, i guess, right ?
>
>   

You are right about new file plugin for xattrs support:
It is important to not break compatibility.
It should be based on some existing file plugin for
regular files (currently there are 2 ones: unix-file plugin
and cryptcompress plugin).

Edward.

Re: The reiser4 programming style is recursive?

[Ralph]

Edward Shishkin Thursday 11 December 2008 23:56:
>> there is no reiser4 transaction manager in place with just
>> the patches, right ?
> Its code can be found in reiser4/txnmgr.c

And is this activated or not ready disabled code?

And transactions cannot be used by a normal user, because linux-vfs does not know anything about transactions and therefore there is no way to communicate a transaction command ? 

>>  And the right balancing code in place would have effects like
>>  optimizing access on hard disk, right?
>  yes
I used gentoo half a year on reiser4 and had no performance issues, but filling was not more than half. There are performance issues with more than 80% of charge and not running the balancing code so that the "dancing trees" are about to really dance?
 
>> I read about the xattr problem, traditional linux xattr is to big to
>> suit in place. This means you have to apply the reiser4-philosophy: A
>> file can have sub files (is not only a file but also a directory of
>> subfiles). Why not creating a new reiser4 specific file type just for
>> xattr.
> 
> Subfiles are impossible because of a problem on vfs level
> related to hardlink functionality. It seems not yet resolved...

Here perhaps I can disagree with you (but keep in mind I am not a kernel hacker and do know nearly as much as the filenames of the reiser4 source):

If subfiles for xattrs that would be the clean reiser4 solution (in respect of reiser4 philosophy). But it surely breaks linux-vfs doctrins: a file has to be just a file and not a directory.
And aiming fast inclusion in mainline kernel _without_ to have to have hard discussions, then a subfile solution is no go for now. 

But for now in our discussion a push aside of linux-vfs doctins: 

Isn't it easy to hide a new xattrs-subfile-plugin from linux-vfs?  
Vfs will not see them. If the reiser4 subsystem is asked about xattrs of some file then vfs will see xattrs but no subfile because of the new to create xattrs plugin (it is hiding its content, even its existence) ! 

And with such a new subfile logic for xattrs you can show the potential of reiser4. For example implementing xattr-subfiles as softlinks pointing to one little place where all xattrs of the whole partition are stored. So they can easily been cached. Performance working with xattrs would trump all other available filesystems. 

And you can give the user the most powerful command ever heard: To change the xattr of thousands of files at once !

Ralph

Re: The reiser4 programming style is recursive?

[Edward Shishkin]

Ralph wrote:
> Edward Shishkin Thursday 11 December 2008 23:56:
>   
>>> there is no reiser4 transaction manager in place with just
>>> the patches, right ?
>>>       
>> Its code can be found in reiser4/txnmgr.c
>>     
>
> And is this activated or not ready disabled code?
>
> And transactions cannot be used by a normal user, because linux-vfs does not know anything about transactions and therefore there is no way to communicate a transaction command ? 
>
>   
>>>  And the right balancing code in place would have effects like
>>>  optimizing access on hard disk, right?
>>>       
>>  yes
>>     
> I used gentoo half a year on reiser4 and had no performance issues, but filling was not more than half. There are performance issues with more than 80% of charge and not running the balancing code so that the "dancing trees" are about to really dance?
>  
>   
>>> I read about the xattr problem, traditional linux xattr is to big to
>>> suit in place. This means you have to apply the reiser4-philosophy: A
>>> file can have sub files (is not only a file but also a directory of
>>> subfiles). Why not creating a new reiser4 specific file type just for
>>> xattr.
>>>       
>> Subfiles are impossible because of a problem on vfs level
>> related to hardlink functionality. It seems not yet resolved...
>>     
>
> Here perhaps I can disagree with you (but keep in mind I am not a kernel hacker and do know nearly as much as the filenames of the reiser4 source):
>
> If subfiles for xattrs

Sorry, I don't understand the above. Both "subfiles" and xattrs are
interfaces to work with file's attributes. If so, then "subfiles for xattrs"
sound like "buttery butter". No?
 
>  that would be the clean reiser4 solution (in respect of reiser4 philosophy). But it surely breaks linux-vfs doctrins: a file has to be just a file and not a directory.
>   

I don't know such vfs doctrine. Who is the keeper of this doctrine? :-)))

> And aiming fast inclusion in mainline kernel _without_ to have to have hard discussions, then a subfile solution is no go for now. 
>
> But for now in our discussion a push aside of linux-vfs doctins: 
>
> Isn't it easy to hide a new xattrs-subfile-plugin from linux-vfs?  
>   

There is a user interface to work with xattrs, so it can not
be hidden from vfs "de facto".

Subfiles mean one more step in the procedure of name resolution.
You should return an allocated inode to vfs for every such subfile.
So subfiles also can not be hidden. There is a temptation to cheat
vfs, so it will think that it deals with usual files, but such cheating
doesn't lead to happy end..

xattrs is ugly, but working solution,
subfiles are nice, but it doesn't work.. ;)

> Vfs will not see them. If the reiser4 subsystem is asked about xattrs of some file then vfs will see xattrs but no subfile because of the new to create xattrs plugin (it is hiding its content, even its existence) ! 
>
> And with such a new subfile logic for xattrs you can show the potential of reiser4. For example implementing xattr-subfiles as softlinks pointing to one little place where all xattrs of the whole partition are stored. So they can easily been cached. Performance working with xattrs would trump all other available filesystems. 
>
> And you can give the user the most powerful command ever heard: To change the xattr of thousands of files at once !
>
> Ralph
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: The... reiser4 with no ambiguity

[Ralph Ulrich]

Edward Shishkin Samstag 13 Dezember 2008 20:30:
> I don't know such vfs doctrine. Who is the keeper of this doctrine?
> :-)))
Please, do not be too ironicle here, because I am not an insider and english is not my motherlanguage. I meant there was a discussion that in the linux mainline kernel there should not be a filesystem which has files that can have files. A file as directory was introduced to unifiy namespace by namesys. 

> Subfiles mean one more step in the procedure of name resolution.
> You should return an allocated inode to vfs for every such subfile.
> So subfiles also can not be hidden. There is a temptation to cheat
> vfs, so it will think that it deals with usual files, but such
> cheating doesn't lead to happy end..
> 
> xattrs is ugly, but working solution,
> subfiles are nice, but it doesn't work.. ;)

First of all I have to understand reiser4 with no ambiguity:

Are reiser4 file-plugins _only_ to handle data effective at low-level (like your compression plugin). I know you stress this quiet often in your mails. Or is it just your focussing for now to get reiser4 mainline?

Is it not possible to introduce new extended features in reiser4 and hide these features vfs? 
In reiser4 there is no such possibility to introduce a new kind of file which is hidden from vfs?

Semantics of reiser5 are totally out of scope here, but I thought of them as implementable above/on reiser4 - reiser4 as the technical grounds for reiser5 (as announced by namesys).

Ralph

Re: The... reiser4 with no ambiguity

[Edward Shishkin]

Ralph Ulrich wrote:
> Edward Shishkin Samstag 13 Dezember 2008 20:30:
>   
>> I don't know such vfs doctrine. Who is the keeper of this doctrine?
>> :-)))
>>     
> Please, do not be too ironicle here, because I am not an insider and english is not my motherlanguage. I meant there was a discussion that in the linux mainline kernel there should not be a filesystem which has files that can have files. A file as directory was introduced to unifiy namespace by namesys. 
>
>   
>> Subfiles mean one more step in the procedure of name resolution.
>> You should return an allocated inode to vfs for every such subfile.
>> So subfiles also can not be hidden. There is a temptation to cheat
>> vfs, so it will think that it deals with usual files, but such
>> cheating doesn't lead to happy end..
>>
>> xattrs is ugly, but working solution,
>> subfiles are nice, but it doesn't work.. ;)
>>     
>
> First of all I have to understand reiser4 with no ambiguity:
>
> Are reiser4 file-plugins _only_ to handle data effective at low-level (like your compression plugin).

Nop.

There can be new features, which
. come from vfs;
. are not related to data storage improvements;
. require a new reiser4 plugin.

A good example - xattrs.

>  I know you stress this quiet often in your mails. Or is it just your focussing for now to get reiser4 mainline?
>
> Is it not possible to introduce new extended features in reiser4 and hide these features vfs? 
>   

Yes, it is possible, but, again, those features should implement
some new (optimal, efficient, safe, reliable, etc.) form of data storage.

> In reiser4 there is no such possibility to introduce a new kind of file which is hidden from vfs?
>   

Yes, it is. For example, there are two regular file plugins in reiser4.
Both are intensively used, but vfs doesn't know about them.

> Semantics of reiser5 are totally out of scope here, but I thought of them as implementable above/on reiser4

Yes, I have pushed some technical concepts of r5 to r4 a year ago..

>  - reiser4 as the technical grounds for reiser5 (as announced by namesys).
>
> Ralph
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

Re: The... reiser4 with no ambiguity

[Ralph Ulrich]

Edward Shishkin Sunday 14 December 2008 20:17:
>>  I know you stress this quiet often in your mails. Or is it just your
>>  focussing for now to get reiser4 mainline?
>> Is it not possible to introduce new extended features in reiser4 and
>> hide these features vfs?
> Yes, it is possible, but, again, those features should implement
> some new (optimal, efficient, safe, reliable, etc.) form of data
> storage.

I have the idea to rewrite reiser4 code to another
language (probably D: has clean syntax, has classes and 
garbage collection) and then to have a demon system in
user space where I can experiment to implement 
sql - database features. My aim is a winfs (Microsoft)
like system where you have both a filesystem api 
and a full featured database.

Could reiser4 fit well to my purpose ?

As of now all plugin types have to be "hard-formatted" 
on the partition. You cannot introduce
new plugins to an existing filesystem, yes? 

The first part of my work would be to enable a special place 
on disk for definitions of used plugins.
 
> Yes, I have pushed some technical concepts of r5 to r4 a year ago..

Here in this mailinglist?

Ralph

Re: The... reiser4 with no ambiguity

[Edward Shishkin]

Ralph Ulrich wrote:
> Edward Shishkin Sunday 14 December 2008 20:17:
>   
>>>  I know you stress this quiet often in your mails. Or is it just your
>>>  focussing for now to get reiser4 mainline?
>>> Is it not possible to introduce new extended features in reiser4 and
>>> hide these features vfs?
>>>       
>> Yes, it is possible, but, again, those features should implement
>> some new (optimal, efficient, safe, reliable, etc.) form of data
>> storage.
>>     
>
> I have the idea to rewrite reiser4 code to another
> language

I am a bit disappointed: I wanted to concentrate efforts
on the Linux port..

>  (probably D: has clean syntax, has classes and 
>   
yup, object-oriented means would be a plus.

> garbage collection) and then to have a demon system in
> user space where I can experiment to implement 
> sql - database features. My aim is a winfs (Microsoft)
> like system where you have both a filesystem api 
> and a full featured database.
>
> Could reiser4 fit well to my purpose ?
>   

You might want a high-performance reiser4 storage level
with EOTTL technology.

File plugins and some methods (plug.file) of item plugins
are heavily integrated with the Linux vm subsystem, so you
will need to rewrite them.

> As of now all plugin types have to be "hard-formatted" 
> on the partition. You cannot introduce
> new plugins to an existing filesystem, yes? 
>   

mm.. We can.
There is a notion of compatible development model "4.X.Y":
http://lwn.net/Articles/226251 (Appendix D)
Ask, if something is not clear.

> The first part of my work would be to enable a special place 
> on disk for definitions of used plugins.
>   

Sorry, can not understand the above.

Common notes:
1. As Flex already said, this project will take a lot of
man-hours. I would add it might be of the same order that
was spent for the original Reiser's project.

2. You might want the plugin design document.
I have promised it will be ready in this September..
Sigh.. Coming soon..

Edward.

Re: The... reiser4 with no ambiguity

[Ralph Ulrich]

Edward Shishkin Wednesday 17 December 2008 22:49:
> I am a bit disappointed: I wanted to concentrate efforts
> on the Linux port..

I would like to create some kind of reiser4-SDK where 
more people can easily experiment with reiser4. 

In my vision reiser4 has a big future as a specialized 
filesystem: A filesystem where you can add special features/logic/semantics perhaps even dynamicly. 

I need a different reiser4: A minimal reiser4 "kernel" with 
common features,  this r4-kernel then loads extensions 
special to a r4 partition directly from that partition. 
I mean the defenitions of extensions but also the code 
of these extensions. So there has to be a common 
interpreter of such extensions included in a r4-"kernel".

This way every r4-"extended"-partition can serve a 
different purpose. Eg think of some semantic 
extensions special to music. Users would mount 
a specialized r4 partition at
/home/username/mymusic
Or for pictures .... etc

I believe reiser4 has a big future with its capabilities 
in a field of special storage. Think of all the new
little "iphone" devices. 
 
>>  (probably D: has clean syntax, has classes and
> yup, object-oriented means would be a plus.
A rewrite would have self-educational purpose for me 
personally and could have documentation effects 
(if done proper) for reiser4 in general.

>> Could reiser4 fit well to my purpose ?
> You might want a high-performance reiser4 storage level
> with EOTTL technology.
EOTTL ??

>> The first part of my work would be to enable a special place
>> on disk for definitions of used plugins.
> Sorry, can not understand the above.
See above notes!

Ralph

Re: The... reiser4 with no ambiguity

[Edward Shishkin]

Ralph Ulrich wrote:
> Edward Shishkin Wednesday 17 December 2008 22:49:
>   
>> I am a bit disappointed: I wanted to concentrate efforts
>> on the Linux port..
>>     
>
> I would like to create some kind of reiser4-SDK where 
> more people can easily experiment with reiser4. 
>   

I am skeptical about expediency of the end product,
especially after taking into account its possible high
cost:  why people can not experiment with reiser4,
say, in uml (user mode linux )?

> In my vision reiser4 has a big future as a specialized 
> filesystem: A filesystem where you can add special features/logic/semantics perhaps even dynamicly. 
>   

Imho specialized filesystem is something like ramfs ;)

> I need a different reiser4: A minimal reiser4 "kernel" with 
> common features,  this r4-kernel then loads extensions 
> special to a r4 partition directly from that partition. 
> I mean the defenitions of extensions but also the code 
> of these extensions. So there has to be a common 
> interpreter of such extensions included in a r4-"kernel".
>
>   

> This way every r4-"extended"-partition can serve a 
> different purpose. Eg think of some semantic 
> extensions special to music. Users would mount 
> a specialized r4 partition at
> /home/username/mymusic
> Or for pictures .... etc
>
> I believe reiser4 has a big future with its capabilities 
> in a field of special storage. Think of all the new
> little "iphone" devices. 
>  
>   
>>>  (probably D: has clean syntax, has classes and
>>>       
>> yup, object-oriented means would be a plus.
>>     
> A rewrite would have self-educational purpose for me 
> personally and could have documentation effects 
> (if done proper) for reiser4 in general.
>
>   
>>> Could reiser4 fit well to my purpose ?
>>>       
>> You might want a high-performance reiser4 storage level
>> with EOTTL technology.
>>     
> EOTTL ??
>
>   

yes, "extents on the twig level", the favourite Hans' feature..

>   
>>> The first part of my work would be to enable a special place
>>> on disk for definitions of used plugins.
>>>       
>> Sorry, can not understand the above.
>>     
> See above notes!
>   

Why to not load the "extensions" from a file?
I don't think, that additional formats to store it
on a "low level" is a good idea and the first
issue to resolve...

Edward.

Re: The reiser4 .... why it is the future

[Ralph Ulrich]

And why we all are waiting:

As it is that much standardized nowadays, because everything is nearly
optimized - for example you cannot expect any new picture format that
is much more effective than jpeg2000, you will have todays pdf standard
in yeas to come ... etc -
because the ways to handle user data nowadays will settle down,
will ever less change - that is the chance for reiser4 with plugins
to come to market. Hans Reiser was a bit early with his efforts.

Now, whenever the data-system (old narrow concept "filesytem") can
handle more and more of the logic itself (through the plugins) the
field of new connected programming logic will wide open!

Ralph (unfortunately not a kernel hacker)

Re: The reiser4 .... what it really means

[Ralph Ulrich]

What this really means is:

They forked reiser4 with brtfs to handly more and more data.

But the fortunate way is to fork the kernel to fit him right to reiser4.
The aim should be to connect the data better and better, to go
aiming little gadgets introducing with some real artificial intelligence.

That is the vision of reiser4!

Ralph

Re: The reiser4 .... what it really means

[Ralph Ulrich]

>> But the fortunate way is to fork the kernel to fit him right to reiser4.

> what kind of drugs you're on ?

OK, to decrease:

Why not a special reiser4 for a special /reiser4data mount where it will
be possible
1. to adapt linux vfs behaviors
2. to experiment with special plugins that make a kind of WinFS (that
   kind of really new features where Ms tried in vain)

Ralph

Re: The reiser4 .... what it really means

[Alexander Lyamin]

On Thu, Dec 11, 2008 at 3:22 PM, Ralph Ulrich <eulenreich@gmx.de> wrote:
>>> But the fortunate way is to fork the kernel to fit him right to reiser4.
>
>> what kind of drugs you're on ?
>
> OK, to decrease:
>
> Why not a special reiser4 for a special /reiser4data mount where it will
> be possible
> 1. to adapt linux vfs behaviors
it does.
actually  VFS implementation is a plugin.

> 2. to experiment with special plugins that make a kind of WinFS (that
>   kind of really new features where Ms tried in vain)
Takes a lot of man-hours. Pointless w/o lots of man-hours.
>
> Ralph
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
connecting the dots

Re: The reiser4 ....SDK for experiments outside kernel

[Ralph]

Alexander Lyamin wrote:
>> 1. to adapt linux vfs behaviors
> it does.
> actually  VFS implementation is a plugin.

Hi Alexander,

I am not a kernel-hacker, but I would like to 
experiment with plugins. Is there a reiser4-SDK like thing 
that enables me to easily setup a reiser4 partition in a bigfile and 
to run a demon which makes my yet to program plugins accessible?

Ralph

Re: The reiser4 ....SDK for experiments outside kernel

[Edward Shishkin]

Ralph wrote:
> Alexander Lyamin wrote:
>   
>>> 1. to adapt linux vfs behaviors
>>>       
>> it does.
>> actually  VFS implementation is a plugin.
>>     
>
> Hi Alexander,
>
> I am not a kernel-hacker, but I would like to 
> experiment with plugins. Is there a reiser4-SDK like thing 
> that enables me to easily setup a reiser4 partition in a bigfile and 
> to run a demon which makes my yet to program plugins accessible?
>   

What this tricky business is for?
Does everyone need this?

Be careful with the notion of plugin: in reiser4 this is only
to manage low-level data storage infrastructure.. That said,
first, you should decide what (useful!) feature related to
(low-level!) data storage do you want to implement, then think
how to implement it in the plugin categories. Most likely you'll
need to add new plugin(s) of existing or (unlikely) new interface.
For example, in order to support (meta)data checksums you'll need
a new node format, and, hence, new node plugin (the NODE interface
already exists).
All other "plugins" should go to vfs, or to various stackable
(distributed) filesystems.

Edward.

Re: The reiser4 ....SDK for experiments outside kernel

[Ralph]

Edward Shishkin wrote:
> Be careful with the notion of plugin: in reiser4 this is only
> to manage low-level data storage infrastructure.. That said,
> first, you should decide what (useful!) feature related to
> (low-level!) data storage do you want to implement, then think
> how to implement it in the plugin categories. Most likely you'll
> need to add new plugin(s) of existing or (unlikely) new interface.
> For example, in order to support (meta)data checksums you'll need
> a new node format, and, hence, new node plugin (the NODE interface
> already exists).
> All other "plugins" should go to vfs, or to various stackable
> (distributed) filesystems.

(meta)data like xattr low-level?

> in reiser4 this is only to manage low-level data storage infrastructure
... at this stage of reiser4 is low-level, because the main effort is inclusion in mainline kernel, I thought...

What if you want to write a storage backend for postgresql where content shall be readable per file syntax: 
cat ./database/contacts/names/name/address/streetname
(Sure, you can have a postgresql service that exports streetnames....) ??

Look at: H. Reiser writes: 
"I am going to do the enhanced semantics first"
( http://marc.info/?l=reiserfs-devel&m=115363946628080&w=2 )

That is not so low-level ?
But, as Chistian Stroetmann just said in this thread:
Namesys philosophy is different than actual reiser4 
aimings?

Ralph

Re: The reiser4 ....SDK for experiments outside kernel

[Edward Shishkin]

Ralph wrote:
> Edward Shishkin wrote:
>   
>> Be careful with the notion of plugin: in reiser4 this is only
>> to manage low-level data storage infrastructure.. That said,
>> first, you should decide what (useful!) feature related to
>> (low-level!) data storage do you want to implement, then think
>> how to implement it in the plugin categories. Most likely you'll
>> need to add new plugin(s) of existing or (unlikely) new interface.
>> For example, in order to support (meta)data checksums you'll need
>> a new node format, and, hence, new node plugin (the NODE interface
>> already exists).
>> All other "plugins" should go to vfs, or to various stackable
>> (distributed) filesystems.
>>     
>
> (meta)data like xattr low-level?
>   

Sure.
It is supposed to be stored on disk.

>   
>> in reiser4 this is only to manage low-level data storage infrastructure
>>     
> ... at this stage of reiser4 is low-level, because the main effort is inclusion in mainline kernel, I thought...
>
> What if you want to write a storage backend for postgresql where content shall be readable per file syntax: 
> cat ./database/contacts/names/name/address/streetname
> (Sure, you can have a postgresql service that exports streetnames....) ??
>
> Look at: H. Reiser writes: 
> "I am going to do the enhanced semantics first"
> ( http://marc.info/?l=reiserfs-devel&m=115363946628080&w=2 )
>
> That is not so low-level ?

I am not a specialist in enhanced semantics.
There is a lot of problems on the storage level ;)

Edward.

Re: The reiser4 ....SDK for experiments outside kernel

[Christian Stroetmann OntoLab]

Dear Ralph;
You wrote:
> Edward Shishkin wrote:
>   
>> Be careful with the notion of plugin: in reiser4 this is only
>> to manage low-level data storage infrastructure.. That said,
>> first, you should decide what (useful!) feature related to
>> (low-level!) data storage do you want to implement, then think
>> how to implement it in the plugin categories. Most likely you'll
>> need to add new plugin(s) of existing or (unlikely) new interface.
>> For example, in order to support (meta)data checksums you'll need
>> a new node format, and, hence, new node plugin (the NODE interface
>> already exists).
>> All other "plugins" should go to vfs, or to various stackable
>> (distributed) filesystems.
>>     
>
> (meta)data like xattr low-level?
>
>   
>> in reiser4 this is only to manage low-level data storage infrastructure
>>     
> ... at this stage of reiser4 is low-level, because the main effort is inclusion in mainline kernel, I thought...
>
> What if you want to write a storage backend for postgresql where content shall be readable per file syntax: 
> cat ./database/contacts/names/name/address/streetname
> (Sure, you can have a postgresql service that exports streetnames....) ??
>
> Look at: H. Reiser writes: 
> "I am going to do the enhanced semantics first"
> ( http://marc.info/?l=reiserfs-devel&m=115363946628080&w=2 )
>
> That is not so low-level ?
> But, as Chistian Stroetmann just said in this thread:
> Namesys philosophy is different than actual reiser4 
> aimings?
>   
Despite the fact that I'm unable to follow the logics of the whole 
thread, I would like to clarifiy that:
I haven't said this. I said (now in full length), that the vision of the 
corporation Namesys for the further development of its system (including 
reiser4 or a successor system) was different after the given 
informations on the not anymore existing Namesys website, than the 
vision of the Linux based project (which I'm not allowed to name here) 
by our corporation. There were no claims about some kinds of actual 
reiser4 aimings.
> Ralph
>
> --
Regards
C. Stroetmann

Re: The reiser4 ....SDK for experiments outside kernel

[Ralph]

Christian Stroetmann OntoLab wrote:
>> But, as Chistian Stroetmann just said in this thread:
>> Namesys philosophy is different than actual reiser4
>> aimings?
>>   
> Despite the fact that I'm unable to follow the logics of the whole
> thread, I would like to clarifiy that:
> I haven't said this. I said (now in full length), that the vision of the
> corporation Namesys for the further development of its system (including
> reiser4 or a successor system) was different after the given
> informations on the not anymore existing Namesys website, than the
> vision of the Linux based project (which I'm not allowed to name here)
> by our corporation. There were no claims about some kinds of actual
> reiser4 aimings.
> Regards
> C. Stroetmann

Hi Christian,
you said some messages before: "No. That's a part of the vision of our Linux based project. The vision  from namesys was a bit different."

And I thought you meant this mailing list people with your phrase "our Linux based project" I did misunderstand You, 
Sorry, Entschuldigung!

> ... (which I'm not allowed to name here)
I read some thread about claiming you are forking reiser4. You know
the guy who created Gentoo? He is now creating funtoo, a fork of Gentoo, which has the aim to make it easy to create forks of Gentoo (see http://blog.funtoo.org/). And Linus Thorwalds has created git, especially to make it easy to branch! You see there are different views in opensource society!

Ralph

Re: The reiser4 .... what it really means

[Christian Stroetmann OntoLab]

Dear Ralph Ulrich;
You wrote:
> What this really means is:
>
> They forked reiser4 with brtfs to handly more and more data.
>   
Who did this?
> But the fortunate way is to fork the kernel to fit him right to reiser4.
No. But you can do it, if you wish to. We follow the classic style.
> The aim should be to connect the data better and better, to go
> aiming little gadgets introducing with some real artificial intelligence.
>   
Yes.
> That is the vision of reiser4!
>   
No. That's a part of the vision of our Linux based project. The vision 
from namesys was a bit different.
> Ralph
>
> --
> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Btw.: Where are the other e-mails from this discussion thread?

With best regards
C. Stroetmann

Re: The reiser4 programming style is recursive?

[Mat]

>Edward Shishkin Thursday 11 December 2008 23:56:
>>> there is no reiser4 transaction manager in place with just
>>> the patches, right ?
>> Its code can be found in reiser4/txnmgr.c

>And is this activated or not ready disabled code?

Hi Ralph,

are you actually using Reiser4 ?

the following tools might be helpful in observing reiser4 during its work:

iotop
htop
atop
...

that way you'll see that (I might err) txnmgr is doing its job during
transactions / i/o stuff

Cheers

Mat