Hi everyone,

Here's a rework of last week's HDIO_GETGEO patch.  Based on all the 
feedback that I received last week, it seems that a better way to 
approach this problem is:

- Store a hd_geometry structure with each dm_table entry.
- Provide a dm getgeo method that returns that geometry (or
   -ENOTTY if there is no geometry).
- Add a dm control ioctl to set the geometry of an arbitrary dm device.
- Modify dmsetup to be able to set geometries.

This way, dmraid can associate geometries with bootable fakeraid 
devices, and dmsetup can be told to assign a geometry to a single-device 
linear/multipath setup as desired.  Furthermore, HDIO_GETGEO callers 
will go away empty-handed if the userspace config tools do not set up a 
geometry, as is the case now.  The decision to assign a geometry (and 
what that should be) is totally deferred to userspace.

So, dm-getgeo_1.patch is a patch to 2.6.16-rc3 that modifies the dm 
driver to store and retrieve geometries.  I chose to attach the 
hd_geometry structure to dm_table because it seemed like a convenient 
place to attach config data.  The only part of this patch that I think 
to be particularly dodgy is the dev_setgeo function, because I'm using 
the dm_target_msg struct to pass the user's hd_geometry into the kernel. 
  I'm not really sure if or how I'm supposed to send binary blobs into 
the dm code, though the piggyback method works adequately.  Obviously, 
this introduces a new dm control ioctl DM_DEV_SETGEO.

The second patch (device-mapper-geometry_1.patch), unsurprisingly, is a 
patch to the userspace libdevmapper/dmsetup code to enable the passing 
of hd_geometry structures to the kernel.

Questions?  Comments?

--D

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>