Also note that the only consumer of this system call is supposed
to be Solaris libshare [V2]. Any enhancement to Solaris sharing
functionality is supposed to be done through libshare and its plugin
infrastructure (for example adding a new type of backend).
The new sharefs is not intended to be used out of libshare [V2] context.
Afshin
On 05/11/10 01:53 PM, Afshin Salek wrote:
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]
