DragonFly kernel List (threaded) for 2007-01
Re: VKernel progress update - 10 Jan 2006
:I think following patch does these:
:1) bridge will not be brought up automaticly
:2) non-existent bridge will not be created
It looks pretty good. I would put the TAP init code from
platform/init.c into its own file, maybe platform/init_tap.c, because
the code is getting fairly sophisticated.
:Except above syntax, I have extended it a little bit:
: will only set real kernel tap0's address and netmask
The netmask should use a CIDR notation, that is a '/' instead of
a ':'. e.g. tap0:10.0.0.1/24
:If you have assigned vkeX's address/netmask on vkernel command line,
:then in vkernel you only need 'ifconfig vkeX up', vkeX will have the
:address/netmask supplied on command line.
:Two sysctls are added for vkeX:
:hw.vkeX.intr_rate (rw), #intr/second, default is 20, valid range is [1, hz]
:hw.vkeX.tap_unit (ro), backend tap(4) interface unit in real kernel
:And now 'ifconfig vkeX' will print backend tap(4) interface in real kernel
:Make sure you have pulled in two tap(4) bug fixing in HAED, before
:trying this patch.
:Please test/review it. Hope I can drive it into repo before 1.8 branching.
I tried '-I auto:bridge0' and specified DHCP in my rc.conf and it
almost worked. For some reason the bridge does not appear to be
transmitting the DHCP response to the TAP interface. Either that
or it is but the tap interface is throwing the packet away before
sending it to the vkernel. After a bunch of messing around dhclient
suddenly started working, but I don't know why. I did have the bridge
interface 'up' and it was associated with both tap0 and nfe0.
Either way I don't think it is a bug in the vkernel code. I think it
is a bug in the bridge/tap link somewhere.
Once you fix that CIDR block specification ( : -> / ), just commit it.