Re: Found: module loading breakage

2002-03-22 Thread Alfred Perlstein

* 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

2002-03-22 Thread Alexander Kabaev

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

2002-03-22 Thread Terry Lambert

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

2002-03-22 Thread Terry Lambert

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

2002-03-22 Thread Alfred Perlstein

* 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

2002-03-22 Thread Matthew Dillon

:* 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

2002-03-22 Thread Terry Lambert

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