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.

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.

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.




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 Elischer<jul...@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





_______________________________________________
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"

Reply via email to