Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 May 2011 12:54:14 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
Cc:        svn-src-head@freebsd.org, Rick Macklem <rmacklem@FreeBSD.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>
Subject:   Re: 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
Message-ID:  <297798401.1116789.1304700854017.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <86aaezzu52.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
> Pawel Jakub Dawidek <pjd@FreeBSD.org> writes:
> > My personal opinion is that supporting such configuration is not
> > worth
> > the efforts and actually I'd prefer to use the same sysctl tree
> > (vfs.nfs.*) and the same fstype (nfs) in both clients. User would
> > decide
> > which to use by loading one kernel module or the other.
> 
> Precisely what I was trying to say.
> 
Well, if running the two clients concurrently isn't a requirement,
how does this sound?

- Get rid of the module building for the old client.
  (ie. delete sys/modules/nfsclient)
  That way there is only one client NFS module to load and there
  isn't any confusion over which one to load and when.
--> then, if anyone wants/needs the old client, they would have to
  build a kernel with "options NFSCLIENT" specified.
  (This wouldn't really affect the diskless NFS root folks, since
   they have to compile a client into the kernel anyhow.

If no client is compiled into the kernel, the new one would be
loaded as a module.

I kinda like this variation because:
1 - It's simple and I know how to do it. (I don't know how to
    handle things like kern_modload() calls inside the mount(2)
    syscall when there are 2 client modules both having fstype
    "nfs", etc and so forth.)
2 - It deprecates the old client, so anyone using it will know
    that they are and most won't switch to the old unless they
    really need to.

The downside is that anyone wanting/needing to switch to the old
client will have to recompile a kernel to do so.

So, does this sound ok? rick



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