NEEDED: A STANDARD USERLAND INTERFACE FOR ADDRESSING AND DOING IO ON DEVICES
----------------------------------------------------------------------------

[Thanks to Joe Thornber, Yura Umanets and Andreas Dilger for discussions on
 this... many (most?) of these ideas are theirs!]

The Problems
------------
 (1) there's no way of getting a list of devices.  Hard problem, since
devices can dynamically appear and disappear.  (Eg: iSCSI - i.e. netblockdevs,
removable media, editting partition tables, etc.)  Prolly should be done
in-kernel.  (What about Hurd?)

 (2) userland fs tools only permit addressing devices via /dev/name-of-device.
Why not permit doing it by volume name?  Or uuid?  If we're going to do
this, we may as well have a standard syntax for it.  The best way is to
have a standard library everyone uses for addressing devices.

 (3) volume management software can't communicate very well with fs
software.  For example, you have to use e2fsadm (not a generic LVM
or ext2 tool, like lvextend or resize2fs) to resize an ext2 logical volume.
More seriously, it isn't obvious how to implement "resize-the-start".

 (4) distro installers can't (easily) support multiple file systems, because
they would have to do all sorts of calls to "mkfs.fs-type", and have
special knowledge of what different fs's can do.  (Eg: external journals,
block size, etc.)  It's do-able, but a maintenance nightmare.

 (5) manipulating file systems depends on the kernel to provide IO access
to logical volumes and partitions.  I'm not convinced if this is a problem.
Observations:
	- if you depend on the kernel, you can't be portable, or at least
	what you support depends on what's in the kernel.  Imagine you
	want to convert from an AIX LVM to Linux LVM, for example...
	Also, traditional kernel interfaces are often insufficient for
	all userland manipulation of FSs/volumes... hence the mess
	EVMS (Enterprise Volume Management System, from IBM) got itself in.
	- not clear how to do resize-the-start


Solution
--------
 * we need a simple "abstract device" library, to:
 	- do IO on a device
 	- address/identify devices
 * address/identify devices solved by libblkid
(http://www-mddsp.enel.ucalgary.ca/People/adilger/blkid/), by Andreas Dilger.
However, it doesn't provide a way for userland to create devices.  This
is a problem for (5)
 * all fs tools should use the library, so we get a standard way
of addressing devices.  It also makes life easier for programs
that want to use the fs libs (like libparted)
 * LVM/RAID tools should also use this library, for the same reason


ways a device can be created/deleted/changed:
* initial boot-up discovery
* hot-plug (removable media, etc.)
* editting (mkfs, parted, ...)
* "deeper probe"
* iSCSI, loopback


Plan TM
-------
* uuid's stored in-kernel.  each block device has one uuid
* probe "as-deep-as-willing" on startup
* libblkid very simple:
	- passed either a handle, or "all", and "deep" or "shallow"
	- probes, and tells the kernel
* only things that deal with file handles need call libblkid.
(eg: libreiserfs, etc. shouldn't deal with file handles!  mkfs.reiserfs,
OTOH, should)


Unanswered Questions
--------------------
What's a good API?  We want read/write, and prolly some struct to represent
each device.  How should the address-space be dealt with?
What happens when a volume is resized?  Is libblkid a good API for
addressing?