Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer jul...@freebsd.org wrote:
On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote:
I just tried something that seems to work, but please dont hit me ^^;;;
in wtap_ioctl I assigned curthread-td_vnet myself to point to a VNET
(saved it when the module first loaded) (I have not created any jails
yet)... and it works... I didnt put any CURVNET macros...
td-td_vnet is exactly what the CURVNET_SET macro sets.
You should use the Macros because we may change the place where we store it.
The vnet for the current thread is picked up from several places depending
on the context,
and it is cleared again when it is not needed. the V_xxx usages in the code
end up being
in effect expanded to curthread-td_vnet.xxx, where each 'xxx' is sort of
like an element in a structure
but not quite.
Now, theoretically we could just leave it set all the time but then it would
be nearly impossible
to find places where we should have changed it, but forgot and just got the
existing one.
if you want to find the correct place to go, then look at the vnet of the
calling process
which should be in the process cred. or just use vnet0.
Can I check it from user space?
I don't understand why you saw a CRED_TO_VNET of 0
I was under the impression that every process/thread in the system would be
on vnet0
in a vimage kernel.
This is how my printf looks like:
struct thread *td = curthread;
struct vnet *v = TD_TO_VNET(td);
struct ucred *cred = CRED_TO_VNET(td-ucred);
struct vnet *td_vnet = td-td_vnet;
printf(td=%p, td-td_vnet=%p, td-td_ucred=%p, TD_TO_VNET=%p,
CRED_TO_VNET=%p\n, td, td_vnet, td-td_ucred, v, cred);
I made a fast search in /usr/src for td_vnet and found it was
assigned only in
int fork1(td, flags, pages, procp):
#ifdef VIMAGE
td2-td_vnet = NULL;
td2-td_vnet_lpush = NULL;
#endif
Maybe something wrong with how I declare my wtap_ioctl:
static struct cdevsw wtap_cdevsw = {
.d_version =D_VERSION,
.d_flags = 0,
.d_ioctl = wtap_ioctl,
.d_name = wtapctl,
};
...
make_dev(wtap_cdevsw,0,UID_ROOT,GID_WHEEL,0600,(const char *)wtapctl);
your stored vnet idea is ok as well, but may go strange if you load the
driver from a vnet jail
and then remove the jail.
Ok, will document it in the code for now
my assumption is that if ath drivers dont use VNET I shouldnt :P
What is wrong with this hack?
br,
P.S. I have printed porting to vnet text to have it always at hand,
but its a bit hard for me... doing my best.
On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischerjul...@freebsd.org
wrote:
On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote:
On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote:
Hi,
Thanx makes more sense, but I have noticed something weired if you can
shade some light on.
I added printfs one when the module is first loaded (static int
event_handler(module_t module, int event, void *arg)):
curthread=0xc3f95870
curthread-td_vnet=0xc3170e00
curthread-td_ucred=0xc3185d00
TD_TO_VNET=0
CRED_TO_VNET=0
Try to load it from laoder on boot; I think that should work as we are
setting the curvent for the kernel startup.
The problem you are seeing is a bug in the current implementation that
you cannot add any physical network interface after the kernel started.
This applies to cardbus/usb/... as well as any kind of ethernet
interface, so a kldload igb should yield it as well.
The fix for that is easy and hard at the same time:
A) either touch all drivers
B) or touch all cloned interfaces and change 3 common lines.
or try to make cloners aware of vimages.
Solution B) is sitting in perforce with the entire stuff that it depends
on and was started with CH=179022,179255 but not limited to that if you
want to have a peek.
What you certainly can do locally to your driver for now is to make a
change like this:
+#ifdef VIMAGE
+ CURVNET_SET(vnet0);
+#endif
ifp = if_alloc(IFT_ETHER);
+#ifdef VIMAGE
+ CURVNET_RESTORE();
+#endif
you don't really need the #ifdef except for readability as CURVNET_XXX
ar
enot defined for !vnet
It's the type A) kind of change from above that will break eventually
in the future.
/bz
--
//Monthadar Al Jaberi
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
I don't understand why you saw a CRED_TO_VNET of 0
I was under the impression that every process/thread in the system
would
be
on vnet0
in a vimage kernel.
This is how my printf looks like:
struct thread *td = curthread;
struct vnet *v = TD_TO_VNET(td);
struct ucred *cred = CRED_TO_VNET(td-ucred);
struct vnet *td_vnet = td-td_vnet;
here's your problem:
strcut vnet *vnet = cred-cr_prison-pr_vnet;
When I add CURVNET_SET(CRED_TO_VNET(curthread-td_ucred)); I get a panic
too...
But your suggestion works if I do like this:
curthread-td_vnet = curthread-td_ucred-cr_prison-pr_vnet;
CRED_TO_VNET(curthread-td_ucred) returns NULL
I wonder how you are building your module and if VIMAGE is properly
defined. If it's not that would explain a lot of things.
I have put options VIMAGE, rebuild both world and kernel.
I can create jails with vnet options...
I build my module with the standard Makefile for modules:
...
KMOD = wtap
...
SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c
.include bsd.kmod.mk
Right but are you building your module along with the kernel or
outside the tree? In the latter case you may want to add soemthing
like
SRCS+= opt_global.h
.if defined(KERNBUILDDIR)
MKDEP= -include ${KERNBUILDDIR}/opt_global.h
.else
CFLAGS+= -include opt_global.h
MKDEP= -include opt_global.h
opt_global.h:
echo #define VIMAGE 1 ${.TARGET}
.endif
and/or point KERNBUILDDIR to where you built your kernels.
Thanks it works now..
One thing you should be aware of is that if you will compile without
KERNBUILDDIR set, your module will not work on a non-VIMAGE kernel.
Unfortuantely we can only have defaults for one or the other in the
case. Worst you may want to only do the echo if there was a command
line option like -DVIMAGE or the like. Note, setting it to 0 will not
do the trick as it would still be defined.
/bz
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
HEADS UP: tenetative plan to merge VIMAGE parts
Hi, I will be at FOSDEM this weekend (if you are as well and want to talk, send me an email off list or try to find me in the crowds). When back next week I plan to extract the initial parts from perforce and merge them to SVN. This will include: 1) vnet socket pushdown. followed by: 2) general VIMAGE framework. and 3) user space changes. probably along with some noise to ddb and documentation. it could be that VIMAGE in HEAD would be unstable for a couple of days during these times. This batch will not yet include actual VNET teardwn or interface cloners changes but will provide the foundation for that. I hope I'll be able to quickly afterwards make the patches for the interface cloners available and in addition to the bridge code posted and the carp code I have, so we can look at the missing cloned interfaces state, while in parallel trying to get ports breakage figured out. I'll keep you updated during next week as things progress and might post merge candidate patches for your testing. Regards, Bjoern -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: HEADS UP: tenetative plan to merge VIMAGE parts
On 2/3/11 11:47 AM, Bjoern A. Zeeb wrote: Hi, I will be at FOSDEM this weekend (if you are as well and want to talk, send me an email off list or try to find me in the crowds). When back next week I plan to extract the initial parts from perforce and merge them to SVN. This will include: 1) vnet socket pushdown. followed by: 2) general VIMAGE framework. and 3) user space changes. probably along with some noise to ddb and documentation. it could be that VIMAGE in HEAD would be unstable for a couple of days during these times. the sooner the better I think This batch will not yet include actual VNET teardwn or interface cloners changes but will provide the foundation for that. I hope I'll be able to quickly afterwards make the patches for the interface cloners available and in addition to the bridge code posted and the carp code I have, so we can look at the missing cloned interfaces state, while in parallel trying to get ports breakage figured out. I'll keep you updated during next week as things progress and might post merge candidate patches for your testing. Regards, Bjoern ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
Hi,
Since we're going to see VIMAGE (partly) committed into HEAD anytime
now, perhaps it would be a good time to make available some clear
developer documentation on how to cope with VIMAGE in the kernel (at
kernel build time or building a module separately). 3rd party driver
vendors will be most interested in this.
PS: it would be very welcoming for such mechanisms to be elegant in
their usage ;)...
Thank you,
Adrian.
On Thu, Feb 3, 2011 at 9:35 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
I don't understand why you saw a CRED_TO_VNET of 0
I was under the impression that every process/thread in the system
would
be
on vnet0
in a vimage kernel.
This is how my printf looks like:
struct thread *td = curthread;
struct vnet *v = TD_TO_VNET(td);
struct ucred *cred = CRED_TO_VNET(td-ucred);
struct vnet *td_vnet = td-td_vnet;
here's your problem:
strcut vnet *vnet = cred-cr_prison-pr_vnet;
When I add CURVNET_SET(CRED_TO_VNET(curthread-td_ucred)); I get a
panic
too...
But your suggestion works if I do like this:
curthread-td_vnet = curthread-td_ucred-cr_prison-pr_vnet;
CRED_TO_VNET(curthread-td_ucred) returns NULL
I wonder how you are building your module and if VIMAGE is properly
defined. If it's not that would explain a lot of things.
I have put options VIMAGE, rebuild both world and kernel.
I can create jails with vnet options...
I build my module with the standard Makefile for modules:
...
KMOD = wtap
...
SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c
.include bsd.kmod.mk
Right but are you building your module along with the kernel or
outside the tree? In the latter case you may want to add soemthing
like
SRCS+= opt_global.h
.if defined(KERNBUILDDIR)
MKDEP= -include ${KERNBUILDDIR}/opt_global.h
.else
CFLAGS+= -include opt_global.h
MKDEP= -include opt_global.h
opt_global.h:
echo #define VIMAGE 1 ${.TARGET}
.endif
and/or point KERNBUILDDIR to where you built your kernels.
Thanks it works now..
One thing you should be aware of is that if you will compile without
KERNBUILDDIR set, your module will not work on a non-VIMAGE kernel.
Unfortuantely we can only have defaults for one or the other in the
case. Worst you may want to only do the echo if there was a command
line option like -DVIMAGE or the like. Note, setting it to 0 will not
do the trick as it would still be defined.
/bz
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
