Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Mar 2002 14:37:21 -0800
From:      Kirk McKusick <mckusick@beastie.mckusick.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        "Brian F. Feldman" <green@FreeBSD.ORG>, arch@FreeBSD.ORG
Subject:   Re: vnode::v_op bugfix / PERFORCE change 8574 for review (fwd) 
Message-ID:  <200203282237.g2SMbLD99685@beastie.mckusick.com>
In-Reply-To: Your message of "Thu, 28 Mar 2002 14:05:22 PST." <3CA393A2.FB67CC2B@mindspring.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
I concur with your suggestion below that the new patch is a better
approach. Your ideal solution below sounds reasonable though I have
not thought it through completely.

	Kirk McKusick

=-=-=-=-=

Date: Thu, 28 Mar 2002 14:05:22 -0800
From: Terry Lambert <tlambert2@mindspring.com>
To: Kirk McKusick <mckusick@beastie.mckusick.com>
CC: "Brian F. Feldman" <green@FreeBSD.ORG>, arch@FreeBSD.ORG
Subject: Re: vnode::v_op bugfix / PERFORCE change 8574 for review (fwd)

Kirk McKusick wrote:
> I believe your proposed fix is both necessary and correct.

It should be noted that this code is the same as Alexander
Kabaev's original proposed patch.

Alexander's new patch, which I also suggested, is to overallocate
the vector area, and then update it in place.

I think that Alexander's new patch is a better workaround for
the problem, both because (as he points out) the pointer fix
fails when the VFS becomes preemptible, and because of the extra
dereference overhead.

I'm not terrifically happy about either one of them, but at
least there is a much lower impact in refactoring the VOP lists
(the new patch) rather than reallocating them, and since both
operations are exceedingly rare (add/remove a new VOP), if one
has to go in, I would prefer that it be Alexander's new one.

Ideally, we would back out the default_vfs.c changes, add a
"next" pointer field into the VOP list, link the list forward
in order of adjacency at startup, and add new VOPs by linking
them onto the end the the chain.

Then none of this hackery would be necessary.


-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203282237.g2SMbLD99685>