Re: vnd.c 1.254

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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 he script fragment quoted ?
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
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 ...

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

kre