Re: vnd.c 1.254

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

On Jan 18,  5:58am, Robert Elz wrote:
}
}     Date:        Sun, 17 Jan 2016 12:42:32 -0800
}     From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
} 
} And from a later message
} (<201601172101.u0HL11cv023268%server.CornerstoneService.ca@localhost>) ...
} 
}   |      The only place the Xen script does look is in /dev.  It seems kind of
}   | strange to be arguing that it is correct for the Xen script to look in /dev,
}   | but that isn't correct for vnconfig -l to do so. After all, they are
}   | essentially doing the same thing in order to find out what vnds exist. 
} 
} Not at all.  They're doing different things for different purposes.  The
} xen script needs to find a special file that it can configure, for that
} looking in /dev (the normal place to find such files) is entirely reasonable.
} [Aside: a config option to specify which vnd device, which could allow the
} special file to be anywhere, would be nice, and probably already exists.]

     Actually, there isn't.  Keep in mind that the Xen stuff is
host OS independent.  Most of the processing is done in code that
is OS independent.  The block script is an interface between the
OS independent code and NetBSD.

} On the other hand, vnconfig is just revealing internal kernel status to
} the user.   The names it prints (vnd0: ...) aren't used for anything else.
} There isn't even any guarantee that /dev/vnd0[a-p] and the kernel vnd0
} are related in any way at all.  They usually will be, but need not.

     True.  But, if you change that, you're just going to be creating
a big headache for yourself.

} That wouldn't bother other users,   No-one should really care which internal
} kernel unit is accessed by a particular vndN[a-z] set of special files.
} 
}-- End of excerpt from Robert Elz