On Tue, May 11, 2010 at 10:53 PM, Afshin Salek <[email protected]> wrote: > 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()|). > > 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?
I am talking about the _general_ observation that such APIs evolve over years and sometimes the lack of such flag fields to define extensions cause trouble, usually in the form of an API change or a 2nd sibling API (or syscall). I've seen that kind of issue crawling-up in things ranging over UNIX, AmigaOS (mainly in the widget API, for AmigaOS2.0 a novel solution was found which (unfortunately) was forgotten in the history of API design (well, |posix_spawn()| has something similar, but that is not suprising since one of the authors once was at CBM)), Motif (e.g. many changes between Motif 1.x and 2.x were exactly about dealing with needed extensions where the original authors didn't imangine possible extensions (or brushed them aside with comments like "we never need it")), X11 (both the core protocol, client libraries and the Xserver driver API), GTK+ etc etc etc. It's always the same story, problem and usually noone cares until it is too late: No flag field (or other method of extension) of a (semi-)public API and later horrible workarounds are invented to deal with the inflexibilty and crawl&&creep around and prey on developer minds. ---- 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]
