[patch] geom_vinum platform fixes

[lulf at stud.ntnu.no]

Siterer "Rick C. Petty" <rick-freebsd at kiwi-computer.com>:

> Attached is a patch against RELENG_6 (but applies cleanly against
> RELENG_7).  It contains a fix to the geom_vinum platform brokenness
> explained in my earlier email.  Please review the patch and provide any
> feedback.  I will try to find a committer to review/commit this and any
> subsequent changes early this week.

Hello,

I've spent a _lot_ of time fixing gvinum, so your previous statements  
saying noone is fixing gvinum really is wrong :)

   I'm sorry this is taking so
long, but there has been much time invested in 7.0 before gvinum. I'm
also in Japan for another two weeks, so I won't be able to continue a
discussion on this right now.

But I agree with your changes, and  I'll review and integrate your changes
to the new code base ASAP, but this will probably not go in until the  
new gvinum
  codebase iscommitted, since that will probably happen before 7.1/6.4 anyway

--
Ulf Lilleengen

>
> Here is a quick overview of the patch.  I've split the reading and writing
> of the on-disk vinum header into separate functions.  The header is read
> by gv_drive_taste() and written by gv_save_config() and gv_rm_drive().
>
> For reads, there are three possible on-disk formats it handles:  the legacy
> i386 and legacy amd64 formats and the current (forward-going) format.  The
> legacy formats are distinguished by the algorithm in
> gv_test_legacy_header_type(), which tests for known zeros, etc.  Both
> legacy formats are stored in little-endian, and this code should work on
> all architectures regardless of endianness.  I use a separate in-memory
> structure to simplify the conversions.
>
> For writes, the patch only supports the new forward-going on-disk format.
> This format is stored in big-endian (network order, also it's easier to
> read with hexdump) and uses a new magic.  This new magic value contains a
> version number which I've started at 1, in case future enhancements are
> made to the on-disk structure.  Note that devices with old formats are
> auto-upgraded when the configuration is written, which does not happen
> unless "gvinum saveconfig" is used or the gvinum configuration is changed
> for any reason.  This lets admins keep using the old format.  All new
> devices added to gvinum will get the new format.
>
> I've tested this patch on 6.3-stable (i386) and 7.0-stable (i386, amd64)
> systems, using vinum configurations created by amd64 & i386 formats and by
> the new format.  Other testers are welcome!
>
> -- Rick C. Petty
>