Re: Found: module loading breakage
* Alexander Kabaev [EMAIL PROTECTED] [020322 21:31] wrote: I used the workaround below to get the system booting again, but it does nothing to solve the real problem. We should probably either update each and every vnode known to the system with the new v_op pointer when needed, or simply start allocating vop_t vectors large enough to hold every vnode operation we know about. Or maybe some VFS guru can propose a better strategy? Good work! I was about to say: why don't you just traverse the system wide list of vnodes and fixup the pointers? Then I realized that there doesn't seem to be a system wide list... :( You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. Feel ambitious? :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. I was thinking about mp-mnt_nvnodelist, unless there are compelling reasons not to trust it. Feel ambitious? :) Feel like reviewing a patch? I will see what I can do on these weekends. -Alfred _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Alfred Perlstein wrote: Good work! I was about to say: why don't you just traverse the system wide list of vnodes and fixup the pointers? Then I realized that there doesn't seem to be a system wide list... :( You could add one, it would be trivial to add a TAILQ_ENTRY to the vnode strcture as well as add/remove the nodes from the list in the vnode allocation and deallocation code. Feel ambitious? :) Add an indirection, and replace the pointer in the indirection pointer, so that everything just works. It will take a doube-indirection to do. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
* Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... Module loading doesn't occur often. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
:* Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: : Matthew Dillon wrote: : Unless I am missing something, vnodes hang off their mount points. : So, effectively, there is a system-wide list. : : The lock on a global traverasl will be pretty ugly... : :Module loading doesn't occur often. :) : :-Alfred Yah. It's ugly, but it should't effect general performance. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Found: module loading breakage
Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020322 23:13] wrote: Matthew Dillon wrote: Unless I am missing something, vnodes hang off their mount points. So, effectively, there is a system-wide list. The lock on a global traverasl will be pretty ugly... Module loading doesn't occur often. :) The VOP recalculation is to provide a default for new VOPs that are added. I'm not sure it's really necessary, since it's supposed to default to not impliemented, and the lookup for a given descriptor in the list should always get that, if it can't find a matching descriptor. I had a recalculation in my code from 1996 because I sorted the entries, and then used an absolute index (doing this would dereference memory off the end of the list for new VOPs). FreeBSD doesn't make this optimization, and takes the overhead of unpacking and repacking every descriptor, and then doing an extra dereference. So it shouldn't need it. Did this come in as part of the default_vops stuff, which was not part of the original design? Precalculating the tables makes sense, but there's an easy way around that: Take a page for each instance, and then rewrite the contents as needed. I don't think you can use the optimization anyway, if you want to proxy the VOP's across a network or the user/kernel boundary for user space FS work, but other than that, it's a ggood instance-time optimization (e.g. leave it there, and instance it with the double dereference for the proxy cases). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message