> There's a patch that we've had for years to allow alternate RPC ports > to work with userspace NFS and co-exist with existing NFS servers.
Ah, I see (I should have checked that sooner). "NFS: allow nfs root mount to use alternate rpc ports". I can likely just pull that into my kernel and have things work fine without changes to runqemu-export-rootfs. > This would have an impact on that functionality, so if we do need to > change those ports, the existing ones should be maintained with some > sort of option to change the nfsroot line. Yep, that makes sense. That said: it isn't completely clear to me that a seperate rpc program number (aka RPC port) is needed to avoid conflicts between 2 nfs instances in this case: - we don't have unfsd register with rpcbind (-p option), so the rpc program numbers won't conflict there. - using nfsroot implicitly adds the 'nolock' option, so there isn't a conflict there - I did my tests with the nfs kernel server running. There wasn't an immdiate issue observed with mounting and accessing both a kernel provided export & a unfsd provided export (using runqemu-export-rootfs) at the same time. Still, I'm not too familiar with all of the ins and outs of nfs. Is there somewhere I've overlooked where the program numbers could conflict? -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
