public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Chris Mason <mason@suse.com>, Linus Torvalds <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org, reiserfs-list@namesys.com, akpm@osdl.org
Subject: I oppose Chris and Jeff's patch to add an unnecessary additional namespace to ReiserFS
Date: Mon, 26 Apr 2004 09:59:26 -0700	[thread overview]
Message-ID: <408D3FEE.1030603@namesys.com> (raw)
In-Reply-To: <1082750045.12989.199.camel@watt.suse.com>

Adding additional namespaces is not a trivial thing to do, though it 
always seems so minor to the person driven by marketing to quickly hack 
something in.

The xattr namespace offers zero functional advantage over the file 
namespace.  The use of '.' instead of '/' is idiotic, see the very short 
paper "The Hideous Name" by Rob Pike  ( www.cs.bell-labs.com/cm/cs/doc/ 
) for why mindlessly varying the separators in hierarchical names 
throughout an OS is a bad idea. 

V4 of ReiserFS accesses all file attributes via the filesystem namespace 
(see our mainpage at www.namesys.com, there is a section on semantics in 
it).  In V4, attributes are just files with peculiar qualities, kind of 
like the files in /proc have peculiar qualities.  V4 adds some 
additional functionality to the filesystem namespace to make this more 
effective (accessing multiple files in one system call, etc.). 

Namespaces are the roads and waterways of an operating system.  The cost 
of developing an operating system is proportional to how many components 
you build into it.  Namespaces are part of what determines whether that 
cost is linear with the number of components, or something worse. 

The expressive power of an operating system is NOT proportional to the 
number of components, but instead is proportional to the number of 
possible connections between its components.  If you fragment the 
namespaces of an OS, you reduce each component to effective interactions 
with only those components in its reduced size namespace.  Designing the 
namespaces of an OS so that they possess closure and are unified may 
seem like a lot of effort, but it is very cost effective compared to 
building many times more other OS components to get the same expressive 
power.

In the free software community you have to produce working code to be 
paid attention to.  We are doing that.  Chris is sending his patch in at 
this time in part because V4 is about to make his work completely 
obsolete.  At the time he started to write the patch he was told that 
ReiserFS was taking this other approach, and his patch would never be 
accepted so he should not write it.  DARPA was then convinced to fund us 
to do the other approach, and we accepted $600k in funding to (among 
other things) extend the filesystem namespace to access security 
attributes effectively.  I have no desire to change direction at the 
last moment before we ship V4 so as to become less elegant.  I also view 
V3 as stable code that should not be disturbed more than minimally 
necessary, and I desire for all new functionality to go into V4 (Chris 
was also told that before his patch was written).

Making it possible to unify operating system namespaces was why ReiserFS 
was created.  I am not in this for the money.  Pasting in an additional 
namespace beyond what Unix had for short term marketing reasons violates 
its soul, and I have no desire to provide support for it as it 
complicates one feature at a time over 30 years.

Please, let our competing solution of more unified naming have this 
ecological niche it can survive in long enough to see if it is the right 
longterm direction for Linux.  It is more work to be elegant, and it 
will cause application writers some short term pain, but in 30 years you 
will not regret trying it.

Please reject the xattr and acl patch for ReiserFS V3, and wait a week 
or two for ReiserFS V4 to ship to you instead.

Hans

  reply	other threads:[~2004-04-26 16:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-23 19:54 [PATCH] reiserfs v3 patches for 2.6.6-rc2 Chris Mason
2004-04-26 16:59 ` Hans Reiser [this message]
2004-04-26 17:31   ` I oppose Chris and Jeff's patch to add an unnecessary additional namespace to ReiserFS Chris Mason
2004-04-26 18:15     ` Hans Reiser
2004-04-26 19:12       ` Mark Hahn
2004-04-26 19:13       ` Chris Mason
2004-04-26 20:40         ` Matthias Andree
2004-04-26 22:20           ` Chris Wright
2004-04-26 23:20           ` Andrew Morton
2004-04-27 17:35           ` Hans Reiser
2004-04-27 18:00       ` Markus   Törnqvist
2004-04-26 19:33   ` Christoph Hellwig
2004-04-27 17:29     ` Hans Reiser
2004-04-27 17:34       ` Christoph Hellwig
2004-04-27 17:58         ` Hans Reiser
2004-04-27 18:04           ` Christoph Hellwig
2004-04-28  0:10             ` Stefan Traby
2004-04-27 18:07           ` Jeff Garzik
2004-04-28  5:51           ` Meelis Roos
2004-04-30 16:14           ` David Masover
2004-05-02  4:14           ` Rob Landley
2004-04-26 19:56   ` Matt H.

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=408D3FEE.1030603@namesys.com \
    --to=reiser@namesys.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=reiserfs-list@namesys.com \
    --cc=torvalds@osdl.org \
    /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