Re: portmap -> map db entirely in filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux