Re: vnd.c 1.254

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

On Jan 18, 12:52am, Robert Elz wrote:
}
}     Date:        Sun, 17 Jan 2016 17:52:16 +0100
}     From:        Manuel Bouyer <bouyer%antioche.eu.org@localhost>
}     Message-ID:  <20160117165216.GA4949%asim.lip6.fr@localhost>
} 
}   | I don't understand that. If you run in /, you get the busy/free devices
}   | in /dev, if you run in /chroot you get the busy/free devices in /chroot/dev.
} 
} But that makes no sense at all, there are only one set of devices, just
} multiple different sets of names for them.   This is why vnconfig should
} not be looking in /dev (as it never did before NetBSD 7)
} 
}   | yes, but that's not how one would use it.
} 
} It might be.  Particularly with something like xen, qemu, virtualbox
} (as a host) it might make sense to have vnd device files with known
} fixed names (root, usr, home ...) in each config directory (accessing
} different kernel vndN's of course), and then have the startup scripts
} not need configuration, or to go hunting for a suitable vnd.

     Currently, there is no simple way of doing that, at least not
for Xen.

}   | One would use vnconfig -l to find a usable device in /dev,
} 
} No, one wouldn't, as is evidenced by the fact that that is not the
} method that the xen config script uses.  It does it the right way
} (which includes looking at what is available in /dev, though if needed,

     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.

} making a new set of vndN's there is trivial - if I used xen enough
} (that is, making new clients frequently) I think I'd have the script just
} MAKEDEV a new one if all the existing entries in /dev were in use.)

     Hrmm...  automagic...

}   | so you need the /dev entry.
} 
} You need a (set of) special files to create and access the device.
} They do not need to be in /dev.

     True, but if you put them elsewhere, you're on your own to
manage them, and I don't see a problem with that.

}   | I say that what's in /dev/ is now relevant because this is what limits
}   | the number of vnd you can use
} 
} No it doesn't.   Not in any way at all.

     Now, you're just splitting hairs.

}   | Older vnconfig -l listing devices without checking that a /dev/ entry
}   | exists may also be seens as a bug.
} 
} No, it wasn't, it told which vnds were in use, and which were free,
} regardless of which path names might be available to access the free ones,
} or which had been used to config the busy ones.   That's useful.
} It is still useful now, except now there are too many free vnd's to
} list, so the rational approach is to deduce which are free given
} knowledge of which are busy.   The information is still there, just
} in a different form.
} 
}   | The only limit is what's in /dev/ so listing what's in /dev is fine.
} 
} But that isn't a limit, and isn't material in any case.
} 
}   | > It did, or should have.   The code that looked in /dev was ripped out.
}   | > If a pullup of that didn't happen, it should have.
}   | 
}   | You can check that. But a pullup that remove a functionality that
}   | has been there for at last 2 release should be rejected.
} 
} I have now, and it looks like the pullup did not happen.   Christos put
} a comment in the commit on head
} 	XXX: pullup to 7 together with the kernel change.
} but it appears as if that did not happen.
} 
} It needs to.   The vnconfig (vndconfig now) and kernel changes are a set,
} one without the other is definitely broken.
} 
} Christos: can you request that please?
} 
}   | You didn't look at the code I guess.
} 
} That's because you're still running the 7.0 release vnconfig (because
} that is what is still on the netbsd-7 branch).  That's simply broken, and
} it is not surprising that you are seeing problems with vnconfig -l.
} 
} Note that all of this occurred because NetBSD 7 got a broken hack to
} vnconfig to work around the change to being a cloning (which ignored
} backwards compat) rather than fixing it in a rational way, which has
} now been done ... just not yet(fully) pulled up to -7 and -7-0
} 
} And this (irrelevant side issue) still doesn't explain what is happening
} with the xen startup, which doesn't use vn{d}config -l   You wouldn't
} even be thinking about it if you had not noticed (largely because of
} the mismatch of vnconfig & kernel) the change while looking for whatever
} the real issue is here.    You also didn't object when the original
} problem, and this solution, were being discussed early last November.
} 
}-- End of excerpt from Robert Elz