On Jan 17, 1:01pm, Robert Elz wrote:
}
} Date: Sat, 16 Jan 2016 23:27:51 +0100
} From: Manuel Bouyer <bou...@antioche.eu.org>
} Message-ID: <20160116222751.ga2...@asim.lip6.fr>
}
} | 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.
}
} jnem...@cue.bc.ca 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
