New Proxy Unix CAP
James Peach
jpeach at samba.org
Sun Apr 20 16:33:33 GMT 2008
On 18/04/2008, at 7:44 PM, Sam Liddicott wrote:
> * Steve French wrote, On 18/04/08 23:26:
>>
>> Sam Liddicott who I think is the guy who gave the WAFS talk at
>> SambaXP
>> could give more details.
>>
>
> Hi James,
>
> The historic thread is here:
> http://lists.samba.org/archive/samba-technical/2008-January/
> 057155.html
>
> - where we discussed the need to provide a means whereby two Samba
> proxies could support additional operations in support of caching/
> proxying/read-ahead and other beneficial WAN-optimising operations.
Is this intended to be an open protocol extension that other SMB
vendors would implement? If so, could you please add documentation to <http://wiki.samba.org/index.php/UNIX_Extensions
>, or a page that is linked from there.
> The conclusion was that ntioctl was the cleanest way to provide that
> channel (allowing windows server based implementations through
> pluggable ioctl handlers), and all that remained was to find a way
> to advertise the capability.
>
> A conversation at SambaXP with Metze, Steve, Tridge concluded that
> the new "who am I" and the "extattr" operations set a good precedent
> for using the unix capabilities bit and a new info level in the unix
> capabilities to advertise the proxy capabilities (I think I got that
> mostly right). (And a different advertisment method would be needed
> for a windows implementation but Tridge knew what that was, I forget).
>
> The actual operations and their definitions are quite fluid at the
> moment but the current definitions can be had at:
> http://repo.or.cz/w/Samba/vfs_proxy.git?a=blob;f=source/librpc/idl/proxy.idl;h=f54c5ac8ecd24d01c01de64db6e5502218b0598c;hb=v4-0-vfs-proxy
So each proxy operation maps to an ioctl operation? Or does the ioctl
interface simple do transact/read/write?
> You will see that currently there is defined is an extended read and
> extended write operation that make use of cache and compression
> between proxies to avoid sending the full read response where
> possible.
>
> There are no stricter definitions or specifications and that
> interface will change in the near future to include different cache-
> based compression techniques;
I'm guessing that the ioctl interface you define is a multiplexor? In
that case, you should add an operation that allows capability
negotiation or versioning so that you don't need to burn an more UNIX
capability bits when your feature set changes.
> but a review of the irc comments by samjam and the mailing list
> posts of Amin Azez will reveal a lot more on the subject. The
> SambaXP slides ought to be up text week sometime I suppose.
Any idea whether there will be audio or video available?
More information about the samba-technical
mailing list