* Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: Hi, > Well, first of all we are moving away from portmap these days since we > need to support IPv6. We currently have an rpcbind implementation > that is ported from Solaris. I had a look at it a few days ago ... far too fat for me. If you really need Ipv6 support on portmap, let's just do it. Shouldn't be such a big job. > But it would make sense to keep the rpcbind service completely in > the kernel. And move more bloat into the kernel ? Isn't it big enough yet ? Actually, I'm working on making the kernel smaller, moving several things into userspace. > That way the kernel RPC services could register with the rpcbind > database directly, and we wouldn't have to worry about reregistering > running RPC services because of a daemon restart. Wouldn't it be easier to just fix the portmapper ? > There's no need to involve permanent storage for rpcbind. There is even no need to have it running all the time, start on demand is enough for some workloads (eg. in embedded/smalldev environments) > Local user-space RPC services might then register via an ioctl() Oh no, please no more ioctl()'s. We should start getting rid of that old relics. > (or other special interface) instead of an actual RPC. And require an rewrite of each RPC service ? What a funny idea ;-o Making a originally IP-based service locally dependent sounds like a strange step back to me ... cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- 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