DragonFlyBSD

Some people might argue that's what GNU screen is for, and fifos might
not be the ideal way (plus, they're not ttys).

This is possible, there are already many programs (on OpenBSD) hooking
in to pf (e.g., openbgpd).

CAM isn't particularly nice though.

We already have SCTP support in-tree :).

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,
--
Thomas E. Spanjaard
tgen@netphreax.net

Why '16'(VKD_MAX) will be a valid number in his patch?

Best Regards,
sephe

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

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..

exactly!

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 :)

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

if (15 < 16) { vkdFile[(15++ = 16)] = optarg; }

Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net

heh, no :)

% cat<<EOF>d.c
main(){int i=0;printf("%d\n", i++);}
EOF
% cc d.c
% ./a.out
0
%

cheers
simon

On Sun, 28 Jan 2007 18:08:58 +0100
"Simon 'corecode' Schubert" <corecode@fs.ei.tum.de> wrote:

yeah.. should have written a test.. doh. the C book I referred to (in
only 24 hours!!) says '++' is higher in the ops than '=' .. blah. Too
bad the 'standard' costs $$

I think the worry was that = happens after ++ and the [] deref..

anyhoo, your right should be safe (and time to get another book)

$ cat assign-incr.c
main () {
int x²= {-1,-1};
int i = 0;
x[i++] = i;
printf("%d, %d\n", x⁰, x¹);
return i;
}
$ cc assign-incr.c
$ ./a.out
0, -1
$ echo $?
1
$

+i returns the new value of i and i+ returns i before being
incremented. See it as a function in that matter.

//Jonas

I've cleaned it up a bit and added some words to the man page. Please
check out http://leaf.dragonflybsd.org/~swildner/multivkd.diff

Can you cvsup and try again? This was due to a bug in get_empty_drive().
When I try your example now, I get:

1. cat vinum.conf
   drive d1 device /dev/vkd1a
   drive d2 device /dev/vkd2a
   drive d3 device /dev/vkd3a
   drive d4 device /dev/vkd4a

1. vinum create -f vinum.conf
   Can't open /dev/vinum/controld: No such file or directory
   1: drive d1 device /dev/vkd1a
   • 1 Can't initialize drive d1: Operation not supported by device
     2: drive d2 device /dev/vkd2a
   • 2 Can't initialize drive d2: Operation not supported by device
     3: drive d3 device /dev/vkd3a
   • 3 Can't initialize drive d3: Operation not supported by device
     4: drive d4 device /dev/vkd4a
   • 4 Can't initialize drive d4: Operation not supported by device
     rm: /dev/vinum: Directory not empty
     Can't create /dev/vinum/controld: File exists
     0 drives:
     0 volumes:
     0 plexes:
     0 subdisks:

Well, regardless of the vinum issue, I think what we already have is
useful enough to be committed.

The only thing I'm wondering about is if we should rename the '-r'
option to the more general '-D' (analogous to -I). Any opinions on this?

I'll commit the patch next weekend if no one objects.

Sascha

Heh, some of those messages were due to me accidentally running two
vkernels using the same disk image.

Here's the correct output:

1. vinum create -f vinum.conf
   1: drive d1 device /dev/vkd1a
   • 1 Can't initialize drive d1: Operation not supported by device
     2: drive d2 device /dev/vkd2a
   • 2 Can't initialize drive d2: Operation not supported by device
     3: drive d3 device /dev/vkd3a
   • 3 Can't initialize drive d3: Operation not supported by device
     4: drive d4 device /dev/vkd4a
   • 4 Can't initialize drive d4: Operation not supported by device
     Can't open /dev/vinum/controld: No such file or directory
     0 drives:
     0 volumes:
     0 plexes:
     0 subdisks:

Sascha

Sascha Wildner wrote:
> I've cleaned it up a bit and added some words to the man page. Please
> check out http://leaf.dragonflybsd.org/~swildner/multivkd.diff

Nifty - I was thinking of pestering the lists to check on it -
because I just know someone had to be using it, especially with
all this new-fangled-filesystem-talk :)

> Can you cvsup and try again? This was due to a bug in get_empty_drive().

will do - although my -CURRENT machines are unavailable at the moment,
so I'll probably manually apply to 1.8 release until a week or so from
now.

Another thing to be noted was that vinum assumes it's using a kernel
module generally, and the vinum docs warn against a static build,
and I had to statically built into the VKERNEL since module support for
vkernels isn't? there yet?...

> Well, regardless of the vinum issue, I think what we already have is
 > useful enough to be committed.

thanks & IMHO agree

> The only thing I'm wondering about is if we should rename the '-r'
 > option to the more general '-D' (analogous to -I). Any opinions on this?

personally I wasn't sure what to use, as '-r' didn't seem to fit,
so -D works and makes more sense (to me) as well.

I'm probably going to look at various command line / config file kinds
of things for the vkernel 'CLI' if you call it that in about a month or
so - right now I'm working on getting my systems installed in a very
repeatable way for some performance & stress tests I want to do shortly.

> I'll commit the patch next weekend if no one objects.

woohoo! thanks!

- Chris

Check out the -U option.

Sascha

Make sure you also take rev. 1.21 of sys/dev/raid/vinum/vinumio.c (see
commits@). Unfortunately I can't test much myself at the moment.

Sascha

I've committed it, thanks!

In the I didn't change -r to -D in the end because we have already
released with vkernel support and it's really not so important anyways.

Sascha

think I responded to the direct copy.. don't want to seem rude, so
thanks again!