Date: Wed, 19 Dec 2001 14:25:38 -0800 (PST) From: Rohit Grover <rohit@gojuryu.com> To: freebsd-fs@freebsd.org Subject: Re: upper limit on # of vnops? Message-ID: <20011219222538.ACBCD36F9@sitemail.everyone.net>
next in thread | raw e-mail | index | archive | help
>3) You can not add VOPs to the table at run time. The best
> you can currently do is to replace placeholder VOPs with
> new VOPs. If you have placeholder VOPs, and you do this
> (see the end of the VOP descriptor array in the generated
> vnode_if.c in the kernel compilation directory), you are
> limited to the number of placeholders that exist. If you
> look at the system call extension code, you will see that
> it has this same limitation.
I wasn't aware of this constraint until now. I was trying to add vnode_ops using a loadable module. You're right, Freebsd 4.3-RELEASE doesn'nt support dynamic addition of vnode ops. The following code (taken from vfs_opv_recalc()) proves the point.
....
for (i = 0; i < vnodeopv_num; i++) {
opv = vnodeopv_descs[i];
opv_desc_vector_p = opv->opv_desc_vector_p;
if (*opv_desc_vector_p)
FREE(*opv_desc_vector_p, M_VNODE);
MALLOC(*opv_desc_vector_p, vop_t **,
vfs_opv_numops * sizeof(vop_t *), M_VNODE, M_WAITOK);
....
I also found out that the reason I was able to add a few vops until now was that the MALLOC (in vfs_opv_recalc() above) was reallocating the memory freed by FREE(). This was made possible by the fact that vfs_opv_numops was under a power-of-2. As soon as I added the 64th vop_t, the vop vectors for all currently active vnodes were freed in vfs_opv_recalc() and the system paniced in a wierd place.
thanks for your help Terry.
rohit.
_____________________________________________________________
http://www.gojuryu.com . What Karate Do was meant to be.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011219222538.ACBCD36F9>