From: "H. Peter Anvin" <hpa@transmeta.com>
Subject: autofs v4: speak now or forever hold your peace
To: autofs@linux.kernel.org (autofs mailing list)
Date: Mon, 22 Feb 1999 05:02:01 -0800 (PST)

Okay, I'm planning to do outline the basic data structures of autofs
v4 over the next several days.  Some features are already a given:

* Multimounts/scaffolding (/net being a special case of this).
* Arbitrary mount point topology, without needing the
  spawn-an-automounter hack.
* Mounting-process information passed to daemon.
* Most of the filesystem data will live in "ready-to-eat" kernel data
  structures (inodes, dentries) as opposed to separate backing store.

A few frequently requested features that are *not* included, so don't
ask:

* Direct mounts.  These appear to require a significant slowdown to the
  entire VFS, and I do not believe this is justifiable.
* lofs.  Not because I don't think it is a good idea if it can be done
  right, but because it is a feature orthogonal to autofs.
* Replicated servers.  This is an NFS issue, not autofs.  This means
  it belongs in mount(8) and the NFS kernel code.  I completely refuse
  to hack in a feature into autofs when it is clear it should be
  provided elsewhere, *especially* when it is a feature like this when
  it would be more useful if provided elsewhere.  After all, why
  should you be able to mount a replicated server from autofs but not
  from /etc/fstab??

However, if there is some key feature that I'm missing, please speak
up now: please send an email explaining the feature and its
justification, and I will try to fit it into the design.

Oh, autofs v4 will be targetted for the 2.3 kernels and libc6.  2.3
because I am planning to ask for certain VFS changes, which probably
won't be possible in the 2.2 kernel series, and libc6 because I need a
thread-safe dynamic linker, which isn't available for libc5.

	-hpa