In case of the re-sharing (sharing with different options) - will the
libshare
issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH?
Or just a SHAREFS_PUBLISH will be issued?
I am asking because the current interfaces are not explicit about the type
- they do not specify if it is a share or a re-share.
It seems that also this proposal is not explicit about that.
<snip from "6930814 share/unshare issues">
SHARE versus RESHARE
The interfaces are not explicit about the type - it is a share or a re-share?
Neither the caller (libshare) specifies if it is doing a share/re-share,
nor the kernel (nfssrv/sharefs) reports back in the return value if it has
done a share or a re-share.
</snip>
Pavel
On 05/05/10 00:25, Tim Haley 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);
>
> Where:
>
> typedef enum sharefs_proto {
> SHAREFS_NFS,
> SHAREFS_SMB
> } sharefs_proto_t;
>
> typedef enum sharefs_op {
> SHAREFS_PUBLISH,
> SHAREFS_UNPUBLISH
> } sharefs_op_t;
>
> Sharefs would be changed from a dynamically loaded module to be part of
> the kernel. When invoked via the system call, sharefs would dynamically
> load the NFS or SMB module as required and call the appropriate op
> (publish or unpublish) registered by the module. The implication being
> that each protocol service would register an op table with sharefs at
> load time and that sharefs would provide an in-kernel API to update
> sharetab. Each protocol service would be responsible for calling the
> sharetab API as shares are added or removed.
>
> The nfssys system call will no longer handle [un]sharing of NFS shares:
> EXPORTFS support will be removed from nfssys_op.
>
> The in-kernel sharefs API would be:
>
> typedef int (*sharefs_sop_t)(sharefs_op_t opcode,
> void *data, size_t datalen);
>
> int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop);
>
> Register with sharefs to receive calls to publish or unpublish
> shares. If sop is a non-NULL pointer the function will
> be registered as the handler for the specified protocol.
> If sop is NULL, the handler for the specified protocol
> will be set to NULL, effectively unregistering the service.
>
> Return values:
> 0 success
> EINVAL Unknown protocol.
>
> typedef struct share {
> struct share *sh_next;
> char *sh_path; /* share path */
> char *sh_resource; /* share name */
> char *sh_fstype; /* protocol string ("nfs" | "smb") */
> char *sh_opts; /* share property string */
> char *sh_descr; /* share description */
> size_t sh_size;
> } share_t;
>
> int sharetab_add(share_t *share);
>
> Add an entry to sharetab. Existing entries are replaced
> with the new entry. All data is copied to sharetab.
>
> Return values:
> 0 success
> EPERM permision denied
>
> int sharetab_remove(share_t *share);
>
> Remove an entry from sharetab. The parameter must contain
> enough information to uniquely identify a sharetab entry.
> For NFS: sh_fstype and sh_path
> For SMB: sh_fstype and sh_resource.
>
> Return values:
> 0 success
> ENOENT entry not found in sharetab
> EPERM permision denied
>
> 4.2 Bug/RFE Number(s):
>
> 6850837
>
> 4.5 Interfaces
>
> _______________________________________________________________
> | Exported Interface | Classification | Comments |
> |________________________|___________________|__________________|
> | sharefs sys-call | Consolidation | Consumed by |
> | | Private | libshare |
> | | | |
> | sharefs_register | Consolidation | Consumed by NFS |
> | | Private | SMB modules |
> | | | |
> | sharetab_add | Consolidation | sharefs kernel |
> | sharetab_remove | Private | API to manage |
> | | | sharetab content |
> |________________________|___________________|__________________|
>
> 4.6. Doc Impact:
>
> N/A
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
>
>
_______________________________________________
opensolaris-arc mailing list
[email protected]
