On Aug 20, 2009, at 3:11 PM, Trond Myklebust wrote:
On Thu, 2009-08-20 at 12:54 -0400, Chuck Lever wrote:
I'm not too concerned. As it says above, this is a sample that
illustrates how you could do it. It does work, though, so people can
definitely use it to test the functionality.
I'm thinking of when we want to add new upcalls, since you went to
some length to generalize this facility. It would be easier to
manage
adding a new script than it would to update an existing one, and an
admin or distributor could control what scripts are present, or
provide their own.
The act of editing a single script is easy enough, but then you have
to worry about updates from the distributor possibly overwriting the
local modifications, and so on, and so on.
A model like /etc/init.d might be easier to manage in the long run.
True, and we might want to consider adding something like that into
nfs-utils.
Yes, I did generalise the facility: I'm planning on redoing the NFSv4
idmapper at some point soon.
It might also work well for an in-kernel statd implementation. The
user script component could manage the persistent monitored host
database, and everything else would live in the kernel.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
