From: David Masover <ninja@slaphack.com>
To: "Vladimir V. Saveliev" <vs@namesys.com>
Cc: Andrew Morton <akpm@osdl.org>,
vda.linux@googlemail.com, linux-kernel@vger.kernel.org,
Reiserfs-List@namesys.com
Subject: Re: reiser4: maybe just fix bugs?
Date: Tue, 01 Aug 2006 11:55:57 -0500 [thread overview]
Message-ID: <44CF879D.1000803@slaphack.com> (raw)
In-Reply-To: <1154444822.10043.106.camel@tribesman.namesys.com>
Vladimir V. Saveliev wrote:
> Do you think that if reiser4 supported xattrs - it would increase its
> chances on inclusion?
Probably the opposite.
If I understand it right, the original Reiser4 model of file metadata is
the file-as-directory stuff that caused such a furor the last big push
for inclusion (search for "Silent semantic changes in Reiser4"):
foo.mp3/.../rwx # permissions
foo.mp3/.../artist # part of the id3 tag
So I suspect xattrs would just be a different interface to this stuff,
maybe just a subset of it (to prevent namespace collisions):
foo.mp3/.../xattr/ # contains files representing attributes
Of course, you'd be able to use the standard interface for
getting/setting these. The point is, I don't think Hans/Namesys wants
to do this unless they're going to do it right, especially because they
already have the file-as-dir stuff somewhat done. Note that these are
neither mutually exclusive nor mutually dependent -- you don't have to
enable file-as-dir to make xattrs work.
I know it's not done yet, though. I can understand Hans dragging his
feet here, because xattrs and traditional acls are examples of things
Reiser4 is supposed to eventually replace.
Anyway, if xattrs were done now, the only good that would come of it is
building a userbase outside the vanilla kernel. I can't see it as doing
anything but hurting inclusion by introducing more confusion about
"plugins".
I could be entirely wrong, though. I speak for neither
Hans/Namesys/reiserfs nor LKML. Talk amongst yourselves...
next prev parent reply other threads:[~2006-08-01 16:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-31 9:26 reiser4: maybe just fix bugs? Denis Vlasenko
2006-07-31 12:38 ` Adrian Bunk
2006-07-31 16:17 ` Horst H. von Brand
2006-07-31 20:06 ` Denis Vlasenko
2006-08-01 15:22 ` Theodore Tso
2006-08-01 2:30 ` Hans Reiser
2006-08-01 10:37 ` Pavel Machek
2006-08-01 13:59 ` Scott J. Harmon
2006-08-02 6:22 ` Jan Engelhardt
2006-08-02 19:53 ` Denis Vlasenko
2006-08-01 8:31 ` Andrew Morton
2006-08-01 2:18 ` Hans Reiser
2006-08-01 11:24 ` Vladimir V. Saveliev
2006-08-01 14:33 ` Andrew Morton
2006-08-01 15:07 ` Vladimir V. Saveliev
2006-08-01 16:55 ` David Masover [this message]
2006-08-01 19:26 ` Nate Diller
2006-08-02 3:54 ` David Masover
2006-08-03 7:46 ` Theodore Tso
2006-08-04 21:09 ` David Masover
2006-08-01 19:14 ` Nate Diller
2006-08-01 11:43 ` Christoph Hellwig
2006-08-01 11:52 ` Nick Piggin
2006-08-01 14:54 ` Andrew Morton
2006-08-01 19:32 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CF879D.1000803@slaphack.com \
--to=ninja@slaphack.com \
--cc=Reiserfs-List@namesys.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vda.linux@googlemail.com \
--cc=vs@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox