Re: multi-vkd support patch for review

["C.Turner" <c.turner@xxxxxxxxxxxxxxxxxxx>]

On Sun, 28 Jan 2007 13:01:36 +0000
"Thomas E. Spanjaard" <tgen@netphreax.net> wrote:

> C.Turner wrote:
> >   - arbitrary VKERNEL tty's via a fifo for 'detached' operation
> 
> Some people might argue that's what GNU screen is for, and fifos
> might not be the ideal way (plus, they're not ttys).

did some more thinking and this was bad word choice - 
Yes - screen has crossed my mind, and probably what I'll use
in the meantime.. but screen has problems too in some cases
(think ":screen /bin/sh" ) pty would be better, agreed. 

Basically, something (exact "something" tbd) to provide (controlled,
secure) access to in-vkernel 'local' tty's outside of the parent 
process of the vkernel..

> 
> >   - auto host-side pf rulesets on vkernel startup 
> >     (to constrain the vkernels)
> 
> This is possible, there are already many programs (on OpenBSD)
> hooking in to pf (e.g., openbgpd).

exactly!

> 
> >   - expanding vkd's into some kind of spoofed cam / scsi bus 
> >     to allow for 'hotswap' vkds , etc.
> 
> CAM isn't particularly nice though.
> 
> >   - importing KAME SCTP, if there's any use for it and I'm capable
> > of it.. (that one just got in my head somehow.. *cough* syslink
> > transport ..?? ;)
> 
> We already have SCTP support in-tree :).

oops.. missed that one.. well.. never mind. 

Basically this was a presumptuous way of asking if it had been thought
of as a potential transport for syslink, more than anything else :)

> 
> > @@ -159,7 +161,8 @@
> >  				netifFile[netifFileNum++] = optarg;
> >  			break;
> >  		case 'r':
> > -			rootImageFile = optarg;
> > +			if ( vkdFileNum < VKD_MAX )
> > +				vkdFile[vkdFileNum++] = optarg;
> >  			break;
> >  		case 'm':
> >  			Maxmem_bytes = strtoull(optarg, &suffix,
> > 0);
> 
> Why not if (vkdFileNum < VKD_MAX) { vkdFile[vkdFileNum] = optarg; 
> vkdFileNum++; }; ? Because now it appears '16' is a valid number,
> where you start counting from 0, meaning a maximum of 17 devices...
> 
> Cheers,

I basically cloned this from the multi-vke code in the above switch..

(had something else, then I looked at that and would be more consistent,
 although I kind of wondered about postincrement here as well..)

But yes.. it on closer inspection it looks like the order of 
operations is out of whack here and above.. 

the checks in init_vkd below, and in vdisk.c:vkdinit() should catch it
anyway, but bugs should be squashed!

Like I said:

"Since I'm pretty out of date on my C, no comments can be too harsh :)"

Let me know how to proceed 
(since this bug seems to be present in other code as well)

Thanks,

- Chris