ok to bump vnd to 32 in XEN0 config?

On Tue, Jan 31, 2006 at 03:06:09AM +0100, Quentin Garnier
wrote:
> On Tue, Jan 31, 2006 at 11:24:01AM +1100, Daniel
Carosone wrote:
> > On Tue, Jan 31, 2006 at 01:16:13AM +0100, Juan RP
wrote:
> > > On Tue, 31 Jan 2006 09:26:38 +1100
> > > Daniel Carosone <dangeek.com.au> wrote:
> > > 
> > > > How hard would it be to make these
cloning-type devices, created on
> > > > demand?  (the devices, not the /dev
nodes, that's another bikeshed 
> > > 
> > > Do you mean a device clonning as was
implemented for bpf(4) or tap(4)
> > > or are you talking about something else?
> > 
> > Yes, just like that, though perhaps a closer
implementation analogue
> > would be the way that sd(4) instances or wedges
can come and go
> > dynamically, just because its disks and not
network devices.
> 
> However the kernel creates the instances, you still
need, for vnd, a
> userland entrypoint to send the 'create' command. 
That's what cloning
> devices are for.
> 
> It shouldn't be too hard to do;  I might have time to
look at it this
> week, but I wouldn't mind if someone else had a try. 
tap(4) should have
> all the necessary logic.  The only thing to take care
of is providing an
> API so that vnconfig can tell the user which device it
has created, and
> that's exactly how the cloning device of tap works.  It
is different from
> bpf(4) in that respect, because bpf is "open once
for each use", i.e. the
> created device doesn't last longer that the time it is
opened.

So, I've thought about that a bit more.  I don't think we
need a cloning
device here.  We just need vnd(4) to create vnd<N>
when the user does
'vnconfig -c vnd<N>'.

-- 
Quentin Garnier - cubecubidou.net - cubeNetBSD.org
"When I find the controls, I'll go where I like, I'll
know where I want
to be, but maybe for now I'll stay right here on a silent
sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.