Participation in developement of Reiser4

Participation in developement of Reiser4

[Piotr Neuman]

Hello

I'm looking for some intresting projects to devote my spare time to. Reiser v4 
is a very promising one, so I would like to ask wheter there are some tasks 
that a relative newbie in kernel programming like me could do. Something like 
kernel-janitor like tasks maybe (code cleanup) or maybe reiser4 tools.

I'm a bit familiar with linux VFS if that can help (I did some work on User 
Mode Linux filesystem called humfs).

I hope I could help...

Regards

Piotr Neuman

ps. I know I could just start making patches to reiser4 and send them right to 
namesys.com but I don't know where to start/what to do ;-)

Re: Participation in developement of Reiser4

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Neuman wrote:
| Hello
|
| I'm looking for some intresting projects to devote my spare time to.
Reiser v4
| is a very promising one, so I would like to ask wheter there are some
tasks
| that a relative newbie in kernel programming like me could do.
Something like
| kernel-janitor like tasks maybe (code cleanup) or maybe reiser4 tools.
|
| I'm a bit familiar with linux VFS if that can help (I did some work on
User
| Mode Linux filesystem called humfs).
|
| I hope I could help...
|
| Regards
|
| Piotr Neuman
|
| ps. I know I could just start making patches to reiser4 and send them
right to
| namesys.com but I don't know where to start/what to do ;-)
|

Well, this is the same advice that applies to everybody looking to
participate in any project. Find something that bothers you, and try to
fix it. The list will be happy to take a look at your patches and give
you pointers on how to improve them. The best way to learn is through
experience.

All I can really give you as far as more specific advice is things I'd
like to see done with reiser4. The most obvious one, and one that should
be a fairly easy place to start, is to add support for the existing
xattr API to manipulate attributes that reiser4 currently provides under
the ..metas "meta-directory." The ..metas directory is quite
contraversial, and I'd hate to see reiser4 fall by the wayside because
it doesn't support a standard API.

If this feature is already implemented, I apologize, I haven't been
following reiser4 development too closely.

As a note to Hans, who I expect will object strenuously to this email,
the issue of the elegance of the files-as-directories approach that
reiser4 users is a debate that will not likely be concluded any time
soon. I think the best thing for reiser4 to do is to cater to its users.
Many users will disable the files-as-directories support because it does
cause conflicts with existing apps. Whether that makes those apps
"buggy" or not is irrelevant: Users will just use another filesystem
rather than bug their favorite software author to adjust to a situation
that no other filesystem presents. Users that want to use the ..metas
approach are free to do so. To quote something that borders on trite
these days, "Since when does Linux eliminate choice?"

- -Jeff


- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBiRAZLPWxlyuTD7IRAiWiAJ9aQczwp0IafGefLwloral7Q8E2bACfSyjj
ckxTYV0AFS1cQS/z1WsGVaI=
=Se78
-----END PGP SIGNATURE-----

Re: Participation in developement of Reiser4

[Hans Reiser]

Jeff Mahoney wrote:


>
> All I can really give you as far as more specific advice is things I'd
> like to see done with reiser4. The most obvious one, and one that should
> be a fairly easy place to start, is to add support for the existing
> xattr API to manipulate attributes that reiser4 currently provides under
> the ..metas "meta-directory." The ..metas directory is quite
> contraversial, and I'd hate to see reiser4 fall by the wayside because
> it doesn't support a standard API.

No, please, don't work on this.

Work on copy on write links, and implement them as a plugin.  Sorry for 
my not responding earlier, I was somehow blanking on needed features 
even though we have a ton of them.

Copy on write links are probably feasible for a beginner.

Alternatively, look for fixmes scattered throughout the code, and fix 
one of them.

Or, find code that needs better commenting and comment it.

>
> If this feature is already implemented, I apologize, I haven't been
> following reiser4 development too closely.
>
> As a note to Hans, who I expect will object strenuously to this email,
> the issue of the elegance of the files-as-directories approach that
> reiser4 users is a debate that will not likely be concluded any time
> soon. I think the best thing for reiser4 to do is to cater to its users.

If I don't add elegance, why bother to write ReiserFS?  There are better 
ways to make money.

> Many users will disable the files-as-directories support because it does
> cause conflicts with existing apps. Whether that makes those apps
> "buggy" or not is irrelevant: Users will just use another filesystem
> rather than bug their favorite software author to adjust to a situation
> that no other filesystem presents. Users that want to use the ..metas
> approach are free to do so. To quote something that borders on trite
> these days, "Since when does Linux eliminate choice?"
>
> -Jeff
>
>
> --
> Jeff Mahoney
> SuSE Labs

Re: Participation in developement of Reiser4

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:
| Jeff Mahoney wrote:
|
|
|>
|> All I can really give you as far as more specific advice is things I'd
|> like to see done with reiser4. The most obvious one, and one that should
|> be a fairly easy place to start, is to add support for the existing
|> xattr API to manipulate attributes that reiser4 currently provides under
|> the ..metas "meta-directory." The ..metas directory is quite
|> contraversial, and I'd hate to see reiser4 fall by the wayside because
|> it doesn't support a standard API.
|
|
| No, please, don't work on this.
|
| Work on copy on write links, and implement them as a plugin.  Sorry for
| my not responding earlier, I was somehow blanking on needed features
| even though we have a ton of them.
|
| Copy on write links are probably feasible for a beginner.
|
| Alternatively, look for fixmes scattered throughout the code, and fix
| one of them.
|
| Or, find code that needs better commenting and comment it.
|
|>
|> If this feature is already implemented, I apologize, I haven't been
|> following reiser4 development too closely.
|>
|> As a note to Hans, who I expect will object strenuously to this email,
|> the issue of the elegance of the files-as-directories approach that
|> reiser4 users is a debate that will not likely be concluded any time
|> soon. I think the best thing for reiser4 to do is to cater to its users.
|
|
| If I don't add elegance, why bother to write ReiserFS?  There are better
| ways to make money.

Hans, you're selling yourself short if you think that the only reason
people would use reiser4 is for the files-as-directories unified
namespace implementation. There is so much focus on benchmarks, other
features, etc that many people do want to use reiser4, but don't want to
adopt the semantics it offers. Tools already exist to do much of what
..metas implements, and people want to use them. There is no denying
that the ..metas interface has the potential to be much more expressive
and powerful than the xattr interface. Right now, though, users don't
want something more expressive and powerful - they want something that
works with what they have.

The whole concept of UNIX mountpoints and the single tree hierarchy is
that you shouldn't ever need to care what kind of filesystem you're on
when using it. Sure, there are small things here and there that change,
but mostly it's of a "this feature is optional, and may be
unimplemented" variety. Offering the standard xattr API *in addition* to
the ..metas interface allows all that existing code to work without any
additional effort.

Not having this support _is losing you users_. There are other parts of
the kernel that depend on the xattr interface working, such as SELinux.
Implementing standard interfaces is the difference between a research
filesystem and a deployable filesystem.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBiTh9LPWxlyuTD7IRAmkqAKCYVOnLyNuegEWzO/ZCtoKc0BDxuACgpfUr
TvO7rdxS9EFrL0E6HSGevhM=
=X+BW
-----END PGP SIGNATURE-----