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

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 2,  8:38pm, oster%cs.usask.ca@localhost (Greg Oster) wrote:
-- Subject: Re: Recent netbsd-5 changes seem to make (autoconfig) raidframe t

| 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.

Yes, but fixing it this way becomes future-proof.

christos