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