On Wed, May 5, 2010 at 12:25 AM, Tim Haley <[email protected]> wrote:
> I am sponsoring the following fast-track for Afshin Salek. This
> proposal condenses the pair of syscalls used independently for sharing
> nfs and cifs into one syscall. Requested binding is Micro/Patch.
>
> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
> This information is Copyright (c) 2010, Oracle and/or its affiliates. All
> rights reserved.
> 1. Introduction
> 1.1. Project/Component Working Name:
> Unified sharing system call
> 1.2. Name of Document Author/Supplier:
> Author: Afshin Salek
> 1.3 Date of This Document:
> 04 May, 2010
>
> 4. Technical Description
>
> 4.1. Details
>
> Currently, two system calls and a door are used to publish shares: the
> nfsys multi-purpose system call to export NFS shares, the sharefs system
> call to update sharetab and an smbd door to publish SMB shares. libshare
> has to call the NFS or SMB service once per file system and then it has
> to call sharefs once per share, which results in 1000's of system calls
> to publish 1000's of shares.
>
> This is a proposal to unify all file sharing via a single system call:
> sharefs. It is also to support of PSARC 2010/124 (libshare V2), which
> requires changes to NFS, SMB and ZFS.
>
> Publishing all shares via a single system call has several advantages:
> simplifies libshare, significantly reduces the number of system calls
> per file system and per share, and improves integration between sharetab
> and the protocol services. Libshare will call sharefs once per file
> system (for each protocol that has something to share) with a list of
> shares and the protocol services will update sharetab by making calls
> to an in-kernel sharefs API. There will be no user space interface to
> update sharetab directly.
>
> Having the protocol services update the sharetab file has two advantages
> for libshare and sharefs: it significantly reduces the number of system
> calls, as explained above, and neither libshare nor sharefs need to
> perform per share error handling. Each protocol service handles its own
> [un]publish operations and is responsible for updating sharetab as
> appropriate. There is no need for the protocol services to return a list
> of individual share results.
>
> The sharefs system call would be changed to accept: a protocol discriminator
> (NFS or SMB), an operation (publish or unpublish) and an opaque pointer to
> share data. The opaque data passes transparently through sharefs between
> the protocol-specific libshare plugin and the protocol service per PSARC
> 2010/124. The new prototype for sharefs would be of the form:
>
> int sharefs(sharefs_proto_t proto, sharefs_op_t opcode,
> void *data, size_t datalen);
Please do me a small favour and add a flags field, e.g. turn this
prototype into:
-- snip --
int sharefs(sharefs_proto_t proto, sharefs_op_t opcode,
void *data, size_t datalen, uint32_t flags);
-- snip --
The idea is that future consumers (e.g. AFS etc.) can use this for
_easy_ extensions without having to change this API again (and please
don't say this is not needed - see |fork()| vs. |forkx()|).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
opensolaris-arc mailing list
[email protected]
