If a new protocol needs to be supported that should be added to sharefs_proto_t. If a new operation needs to be supported that should be added to sharefs_op_t.
So, what kind of extension are you talking about here? Afshin On 05/11/10 01:49 PM, Roland Mainz wrote:
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
_______________________________________________ opensolaris-arc mailing list [email protected]
