Re: [2.6] Most likely to be merged by Halloween... THE LIST

[Alasdair Kergon]

On Sun, Jul 21, 2002 at 04:10:50PM +0200, Andi Kleen wrote:
> The problem in my opinion with LVM2 is that the design makes it
> near impossible to get a stable ABI between user and kernel space
> (at least if you don't want to freeze it completely). 

> As far as I can see this problem is not addressed in LVM2 and its design
> makes it even harder to address than it was in LVM1

On the contrary, device-mapper (which is the name we have given to the
generic kernel driver that LVM2 uses) goes out of its way to learn
these lessons from LVM1 and to provide mechanisms so we can avoid this
sort of potential problem as new features are added etc.

Of course we hope the existing interface is reasonably stable and
changes will just be additions to support new features.  But
nevertheless LVM2/device-mapper is designed to cope with all sorts of
scenarios, including a single version of userspace tools working
sensibly with both older *and newer* versions of the kernel driver.

We have three layers:
  +------------+---------+------------+
  | LVM2 Tools | dmsetup | Other apps |  Userspace apps
  +------------+---------+------------+
  | device-mapper library             |  Userspace library
  +-----------------------------------+
  | device-mapper                     |  Kernel driver
  +-----------------------------------+

Userspace library/kernel driver interface:
  LVM1 attached a single version number to this ioctl interface,
  and a version number mismatch meant the tools would fail.

  The device-mapper ioctl interface attaches a 3-component version
  number to each individual command so we can handle fine-grained 
  forwards and/or backwards compatibility easily if we need to - and 
  in either the kernel or in the library as appropriate.

Alasdair
-- 
[e-mail]