Re: vnd.c 1.254

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 17,  1:01pm, Robert Elz wrote:
}
}     Date:        Sat, 16 Jan 2016 23:27:51 +0100
}     From:        Manuel Bouyer <bouyer%antioche.eu.org@localhost>
}     Message-ID:  <20160116222751.GA2083%asim.lip6.fr@localhost>
} 
}   | Also, you don't address the problem that, as I understand it and if
}   | the code works properly, vnconfig -l won't show free devices if the
}   | first 4 are in use.
} 
} Arguably it shouldn't show any free devices at all, otherwise, where
} should it stop?   The correct answer to "which vnd is free?" is "any
} vnd that is not is use."   Attempting to enumerate them all is folly.
} 
} The current scheme (I believe) lists a vnd as free (not in use) if
} some higher vnd is (or has been) used, and stops when the highest one
} ever used is reached.   Or at least that's the intent.   But removing
} all of the output for unused vnds would probably be a good idea.
} 
} If you want to know what is configured in /dev, then "ls /dev/vnd*d"
} will show you that, but there is no particular reason that vnd's
} (or any devices) need to exist in /dev (consider in a chroot partition,
} which might have /dev/vnd23[a-p] only)
} 
} There original problem was caused with the way vn{d}config was hacked
} to handle -l when vnd was made cloning (that lost backward compat to
} netbsd 6, which was the bug reported which the fixes in question were
} handling).  But there was no way to fix vnd and vn{d}config that would
} retain 100% backward compat in all cases.  Since NetBSD 7 was so new,
} some compat was lost just for it, you really do not want to run vnd
} related stuff from netbsd 7 release except with everything from its
} own version - upgrade to what is now on the relevant branch, or what
} is in current, but do both vnd.c and vndconfig at the same time.
} 
} But if you have vndconfig & a kernel built from the same set of sources,
} it should work.   But various mismatches have different sets of problems.
} Which particular problem depends upon just which version of vn{d}config
} and which version of vnd.c happen to be in use.
} 
} jnemeth%cue.bc.ca@localhost said:
}   | It would appear that the call to vnconfig is failing.
}   | The question is, why?
} 
} Yes, good question.   What is $xparams in [t]he script fragment quoted ?

     It's the path to the file to be used as backing store (confirmed
to exist and be a regular file by an earlier call to stat(1)).
Its original source is the config file for the domU.

} Currently, it is possible to configure any unused vnd (so if $xparams
} is doing that it should work) (it is also possible to vndconfig -l

     As shown in the script fragment, $xparams has nothing to do with
the choice of which vnd to use.

} any device) but other uses are likely to return an error when used on
} an unconfig'd vnd
} 
}   | What happens if you have 9 or fewer /dev/vnds?
} 
} Should be irrelevant.
} 
}   | My thought here is about sort order where vnd10 would come before vnd2
} 
} No, the script extracts just the N part of the vnd names, and uses sort -n
} so the sort will produce 0 1 2 3 ... 10 11 ...

     Oops, right.

} But in any case:
} 
}   | and what happens if you try to configure them out of order.
} 
} Nothing very interesting, vnds (or any similar cloning device) can be
} configured in any order you like.
} 
} Incidentally, possibly depending on just what $xparams is, that script
} fragment looks like it should work fine to me - it uses safe methods
} to work out which vnd is available from what I can see (the script
} wants to use /dev/vnd* so it looks to see what is there, it cannot
} use anything which isn't) and then it removes from consideration any
} vnd which is in use (for which it uses $( sysctl hw.disknames )
} which is the safest way to see what is actually in use.
} 
} It isn't using vnconfig -l, which is the only thing that was (or should
} have been) affected by the vnd.c (and related vndconfig) changes.  That
} is, unless it is attempting to set a geometry with a sector size that is
} not a power of 2 - another of the changes in the set causes that to error

     The only call to vnconfig to configure a vnd (there is a
vnconfig -u elsewhere in the script) and as you saw it is nothing
more then:

vnconfig /dev/vnd<n>d <file>

} out, whereas previously it would have been accepted (and who knows what
} would have happened had it been actually used that way - these days much of
} the kernel assumes only power of two sector sizes, shifting is used to
} adjust units.)
} 
}-- End of excerpt from Robert Elz