svn commit: r221124 - in head: . sbin/mount sbin/mount_nfs sys/amd64/conf sys/fs/nfsclient sys/i386/conf sys/ia64/conf sys/nfsclient sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[Rick Macklem]

> Rick Macklem <rmacklem at uoguelph.ca> writes:
> > Well, another way it could be handled would be to put the sysctls
> > and
> > the global variables they manipulate in a module shared by both
> > clients,
> > like sys/nfs/nfs_lock.c (module "nfslock"). Then the same sysctl
> > would
> > affect both clients. (I hesitate to create "yet another" module just
> > to share the sysctls, but since "nfslock" is used by both clients,
> > it
> > should work ok, I think.)
> 
> I don't understand why you would want to do that. Can't you just
> change
> "oldnfs" back to "nfs" in the old stack?
> 
> Hmm, it occurred to me that there is currently no way to tell the
> kernel
> that two drivers conflict with eachother. Perhaps I should take a shot
> at implementing a DRIVER_CONFLICT macro to mirror DRIVER_DEPEND.
> 
Also, except for the SYSCTL() naming issue they don't comflict. At the
moment it is perfectly ok to use both for mounts concurrently.
For example, you could have the following 2 lines in your /etc/fstab:

nfs-server:/sub1    /mnt    nfs    rw      0    0
nfs-server:/sub2    /mnt2   oldnfs rw      0    0

I don't know why you would actually choose to do this, unless you found
that the old NFS client did something that worked better for "/sub2" for
your purposes, but it will work fine.

rick
ps: The issue you pointed out in the first post is just a line in
    /etc/rc.d/mountcritremote that needs to be fixed. It uses a
    module name of "nfs" and "nfsclient" when the new NFS is
    "nfs" and "nfscl" (the old one is "oldnfs" and "nfsclient").
    That's easy to fix. I'm just waiting for a review.