Re: Recent netbsd-5 changes seem to make (autoconfig) raidframe trouble

[Greg Oster <oster%cs.usask.ca@localhost>]

On Thu, 2 Dec 2010 20:39:41 -0500
christos%zoulas.com@localhost (Christos Zoulas) wrote:

> On Dec 2,  4:03pm, oster%cs.usask.ca@localhost (Greg Oster) wrote:
> -- Subject: Re: Recent netbsd-5 changes seem to make (autoconfig)
> raidframe t
> 
> | Sorry for the delay in responding...  :( 
> | 
> | I think all we need to do is to make a call to getdisksize() were
> | numBlocksHi is being set in rf_disks.c:rf_AutoConfigureDisks().  The
> | necessary ac->vp sitting right there, so that should be easy.  It's
> | then just a matter of determining if ((numBlocksHi<<32)+numBlocks)
> is | larger than the size that the disklabel claims.  (and, if so,
> | discounting the numBlocksHi field, and setting it back to zero so
> that | it's correct the next time...)
> 
> That's sounds ok, but why not use the version number to determine if
> they are populated or not like I was suggesting in the first place?

The issue with version numbers is that they are broken with respect to
component labels -- the versioning checks currently check for
equialency, rather than "<=" some version number.  That means that if
we bump the version number, then we end up writing out component labels
which are no longer compatible with older kernels :(  The only way
around that will be to (again) use some unused space in the component
labels to indicate a sub-version, and then key off of that to determine
the capabilities/values that the component labels describe/provide.

Later...

Greg Oster