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"
