From owner-freebsd-fs Wed Dec 19 14:26: 2 2001 Delivered-To: freebsd-fs@freebsd.org Received: from omta02.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by hub.freebsd.org (Postfix) with ESMTP id 4158337B623 for ; Wed, 19 Dec 2001 14:25:39 -0800 (PST) Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta02.mta.everyone.net (Postfix) with ESMTP id C80B51C379C for ; Wed, 19 Dec 2001 14:25:38 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id ACBCD36F9; Wed, 19 Dec 2001 14:25:38 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Wed, 19 Dec 2001 14:25:38 -0800 (PST) From: Rohit Grover To: freebsd-fs@freebsd.org Subject: Re: upper limit on # of vnops? Reply-To: rohit@gojuryu.com X-Originating-Ip: [65.194.57.194] Message-Id: <20011219222538.ACBCD36F9@sitemail.everyone.net> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >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