From sacadmin Wed Dec 2 14:24:24 2009 Received: from sunraf.sfbay.sun.com (sunraf.SFBay.Sun.COM [10.6.180.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2MOOMN000994; Wed, 2 Dec 2009 14:24:24 -0800 (PST) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nB2MLhXF138457; Wed, 2 Dec 2009 14:21:43 -0800 (PST) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id nB2MLg61138453; Wed, 2 Dec 2009 14:21:42 -0800 (PST) Date: Wed, 2 Dec 2009 14:21:42 -0800 (PST) From: "Roger A. Faulkner" Message-Id: <200912022221.nB2MLg61138453@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: delete obsolete system call traps [PSARC/2009/657 FastTrack timeout 12/09/2009] Status: RO Content-Length: 572 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: delete obsolete system call traps 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 02 December, 2009 4. Technical Description See the case directory for more detail 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 From Roger.Faulkner@sun.com Wed Dec 2 14:42:47 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2MglkZ001649 for ; Wed, 2 Dec 2009 14:42:47 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nB2MgkRQ644697; Wed, 2 Dec 2009 14:42:46 -0800 (PST) Message-Id: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> Date: Wed, 2 Dec 2009 14:42:46 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: delete obsolete system call traps [PSARC/2009/657] To: psarc-ext@sac.sfbay.sun.com Cc: Bart.Smaalders@sun.com, bryan.cantrill@sun.com, michael.shapiro@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: si4sEY5WNnrpCw3jo1FAVg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 5039 I am sponsoring this fast-track case for myself. No external/ABI interfaces are changing, so there is no documentation change. The release binding is "minor", so it can be done in solaris_nevada (Solaris Next, OpenSolaris) (this will never be back-ported). DISCUSSION: Over the years, a number of system call traps have fallen into an unused/obsolete state. These are never called from libc, as in the case of: /* * Obsolete lwp_mutex_lock() interface, no longer called from libc. * libc now calls lwp_mutex_timedlock(lp, NULL, NULL). * This system call trap continues to exist solely for the benefit * of old statically-linked binaries from Solaris 9 and before. * It should be removed from the system when we no longer care * about such applications. */ int lwp_mutex_lock(lwp_mutex_t *lp) { return (lwp_mutex_timedlock(lp, NULL, NULL)); } There are cases where two traps do the same thing. For example: dup(fd) is exactly the same as: fcntl(fd, F_DUPFD, 0) The dup() syscall trap can be eliminated in favor of fcntl(fd, F_DUPFD, 0) (in dup() as implemented in libc). PROPOSAL: The time has come to actually delete these obsolete/redundant system call traps from the kernel and free their system call numbers for reuse by future, yet-to-be-invented system calls. The *at() system calls were introduced in Solaris 9: openat() openat64() fstatat() fstatat64() fchownat() unlinkat() renameat() accessat() These functions are a super-set of the corresponding traps: open() open64() fstat() fstat64() fchown() unlink() rename() access() all of which can be implemented in libc using calls to the corresponding *at() system call traps. There is no need to have such duplicate functionality in the system call traps. Aside: There is a bug fix in the libc open() function that did not get implemented in the libc openat() function. Such errors are a consequence of having two system call traps that perform esentially the same operation. A bug fix in one can be neglected in the other. There should be only one. Finally, the *at() system calls were implemented as subcodes of a single trap number, SYS_fsat. These system calls are important enough for each to have its own system call trap number. These old system call traps are already never called from libc. They can just be deleted from the kernel: fork() forkall() utime() utimes() futimesat() poll() lwp_mutex_lock() lwp_sema_wait() wait() These system call wrapper functions can be reimplemented in libc as shown amd then the old system call traps can be deleted from the kernel: open(path, flag, ...) openat(AT_FDCWD, path, flag, ...) creat(path, ...) open(path, O_WRONLY | O_CREAT | O_TRUNC, ...) open64(path, flag, ...) openat64(AT_FDCWD, path, flag, ...) creat64(path, mode) open64(path, O_WRONLY | O_CREAT | O_TRUNC, mode) unlink(path) unlinkat(AT_FDCWD, path, 0) rmdir(path) unlinkat(AT_FDCWD, path, AT_REMOVEDIR) chown(path, uid, gid) fchownat(AT_FDCWD, path, uid, gid, 0) lchown(path, uid, gid) fchownat(AT_FDCWD, path, uid, gid, AT_SYMLINK_NOFOLLOW) fchown(fd, uid, gid) fchownat(fd, NULL, uid, gid, 0) stat(path, &sb) fstatat(AT_FDCWD, path, &sb, 0) lstat(path, &sb) fstatat(AT_FDCWD, path, &sb, AT_SYMLINK_NOFOLLOW) fstat(fd, &sb) fstatat(fd, NULL, &sb, 0) stat64(path, &sb) fstatat64(AT_FDCWD, path, &sb, 0) lstat64(path, &sb) fstatat64(AT_FDCWD, path, &sb, AT_SYMLINK_NOFOLLOW) fstat64(fd, &sb) fstatat64(fd, NULL, &sb, 0) xstat(vers, path, &sb) stat(path, &sb) lxstat(vers, path, &sb) lstat(path, &sb) fxstat(vers, path, &sb) fstat(path, &sb) xmknod(vers, path, ...) mknod(path, ...) dup(fd) fcntl(fd, F_DUPFD, 0) rename(oldnam, newnam) renameat(AT_FDCWD, oldnam, AT_FDCWD, newnam) access(fname, amode) faccessat(AT_FDCWD, fname, amode, 0) All of this is possible without sacrificing any part of binary compatibility due to the Solaris 10 Branded Zone project, integrated into onnv-gate in build snv_127. See: PSARC 2009/253 S10C 6666646 Solaris 10 zones on OpenSolaris binary (supported) distributions http://hub.opensolaris.org/bin/view/Community+Group+zones/s10brand_dev_guide As part of deleting old system call traps from the kernel, changes must be made to: usr/src/lib/brand/solaris10 and: usr/src/uts/common/brand/solaris10 to emulate the deleted system call traps. Any process running in a Solaris 10 branded zone will see a kernel interface identical to that of Solaris 10 itself. There will be an impact on dtrace(1M) in scripts that assume knowledge of the details of the system call trap interfaces. For example, instead of: syscall::open syscall::open64 you have to type: syscall::openat syscall::openat64 and you also have to change 'arg0' to 'arg1' (for ::openat:entry). See the bugid: 6906485 delete obsolete system call traps Roger Faulkner From gdamore@sun.com Wed Dec 2 15:18:47 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB2NIlgI003297 for ; Wed, 2 Dec 2009 15:18:47 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB2NIlp0019829 for ; Wed, 2 Dec 2009 15:18:47 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB2NIfss005887 for ; Wed, 2 Dec 2009 15:18:41 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100B00SN2PF00@fe-sfbay-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 15:18:41 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU100IUASR0GDC0@fe-sfbay-10.sun.com>; Wed, 02 Dec 2009 15:18:37 -0800 (PST) Date: Wed, 02 Dec 2009 15:18:36 -0800 From: "Garrett D'Amore" Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-reply-to: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Message-id: <4B16F5CC.1050104@sun.com> References: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 5421 Roger A. Faulkner wrote: > I am sponsoring this fast-track case for myself. > > No external/ABI interfaces are changing, so there is no documentation change. > > The release binding is "minor", > so it can be done in solaris_nevada (Solaris Next, OpenSolaris) > (this will never be back-ported). > > DISCUSSION: > > Over the years, a number of system call traps have fallen > into an unused/obsolete state. These are never called > from libc, as in the case of: > > /* > * Obsolete lwp_mutex_lock() interface, no longer called from libc. > * libc now calls lwp_mutex_timedlock(lp, NULL, NULL). > * This system call trap continues to exist solely for the benefit > * of old statically-linked binaries from Solaris 9 and before. > * It should be removed from the system when we no longer care > * about such applications. > */ > int > lwp_mutex_lock(lwp_mutex_t *lp) > { > return (lwp_mutex_timedlock(lp, NULL, NULL)); > } > > There are cases where two traps do the same thing. > For example: > dup(fd) > is exactly the same as: > fcntl(fd, F_DUPFD, 0) > The dup() syscall trap can be eliminated in favor of > fcntl(fd, F_DUPFD, 0) (in dup() as implemented in libc). > > PROPOSAL: > > The time has come to actually delete these obsolete/redundant > system call traps from the kernel and free their system call > numbers for reuse by future, yet-to-be-invented system calls. > > The *at() system calls were introduced in Solaris 9: > openat() > openat64() > fstatat() > fstatat64() > fchownat() > unlinkat() > renameat() > accessat() > These functions are a super-set of the corresponding traps: > open() > open64() > fstat() > fstat64() > fchown() > unlink() > rename() > access() > all of which can be implemented in libc using calls to the > corresponding *at() system call traps. There is no need > to have such duplicate functionality in the system call traps. > > Aside: There is a bug fix in the libc open() function that > did not get implemented in the libc openat() function. > Such errors are a consequence of having two system call traps > that perform esentially the same operation. A bug fix in one > can be neglected in the other. There should be only one. > > Finally, the *at() system calls were implemented as subcodes > of a single trap number, SYS_fsat. These system calls are > important enough for each to have its own system call trap number. > > These old system call traps are already never called from libc. > They can just be deleted from the kernel: > > fork() > forkall() > utime() > utimes() > futimesat() > poll() > lwp_mutex_lock() > lwp_sema_wait() > wait() > > These system call wrapper functions can be reimplemented in libc as shown > amd then the old system call traps can be deleted from the kernel: > > open(path, flag, ...) openat(AT_FDCWD, path, flag, ...) > creat(path, ...) open(path, O_WRONLY | O_CREAT | O_TRUNC, ...) > open64(path, flag, ...) openat64(AT_FDCWD, path, flag, ...) > creat64(path, mode) open64(path, O_WRONLY | O_CREAT | O_TRUNC, mode) > unlink(path) unlinkat(AT_FDCWD, path, 0) > rmdir(path) unlinkat(AT_FDCWD, path, AT_REMOVEDIR) > chown(path, uid, gid) fchownat(AT_FDCWD, path, uid, gid, 0) > lchown(path, uid, gid) fchownat(AT_FDCWD, path, uid, gid, AT_SYMLINK_NOFOLLOW) > fchown(fd, uid, gid) fchownat(fd, NULL, uid, gid, 0) > stat(path, &sb) fstatat(AT_FDCWD, path, &sb, 0) > lstat(path, &sb) fstatat(AT_FDCWD, path, &sb, AT_SYMLINK_NOFOLLOW) > fstat(fd, &sb) fstatat(fd, NULL, &sb, 0) > stat64(path, &sb) fstatat64(AT_FDCWD, path, &sb, 0) > lstat64(path, &sb) fstatat64(AT_FDCWD, path, &sb, AT_SYMLINK_NOFOLLOW) > fstat64(fd, &sb) fstatat64(fd, NULL, &sb, 0) > xstat(vers, path, &sb) stat(path, &sb) > lxstat(vers, path, &sb) lstat(path, &sb) > fxstat(vers, path, &sb) fstat(path, &sb) > xmknod(vers, path, ...) mknod(path, ...) > dup(fd) fcntl(fd, F_DUPFD, 0) > rename(oldnam, newnam) renameat(AT_FDCWD, oldnam, AT_FDCWD, newnam) > access(fname, amode) faccessat(AT_FDCWD, fname, amode, 0) > > All of this is possible without sacrificing any part of binary > compatibility due to the Solaris 10 Branded Zone project, > integrated into onnv-gate in build snv_127. See: > > PSARC 2009/253 S10C > 6666646 Solaris 10 zones on OpenSolaris binary (supported) distributions > > http://hub.opensolaris.org/bin/view/Community+Group+zones/s10brand_dev_guide > > As part of deleting old system call traps from the kernel, > changes must be made to: > usr/src/lib/brand/solaris10 > and: > usr/src/uts/common/brand/solaris10 > to emulate the deleted system call traps. > > Any process running in a Solaris 10 branded zone will see > a kernel interface identical to that of Solaris 10 itself. > Will this change also be made for the Solaris 8 branded zone? - Garrett > There will be an impact on dtrace(1M) in scripts that assume > knowledge of the details of the system call trap interfaces. > For example, instead of: > syscall::open > syscall::open64 > you have to type: > syscall::openat > syscall::openat64 > and you also have to change 'arg0' to 'arg1' (for ::openat:entry). > > See the bugid: > 6906485 delete obsolete system call traps > > Roger Faulkner > > From Roger.Faulkner@sun.com Wed Dec 2 17:36:13 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB31aDhI006352 for ; Wed, 2 Dec 2009 17:36:13 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nB31aDkJ686325; Wed, 2 Dec 2009 17:36:13 -0800 (PST) Message-Id: <200912030136.nB31aDkJ686325@jurassic-x4600.sfbay.sun.com> Date: Wed, 2 Dec 2009 17:36:13 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: delete obsolete system call traps [PSARC/2009/657] To: gdamore@sun.com Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MDLy6/d24zD6ad6C2DWRTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1018 > Date: Wed, 02 Dec 2009 15:18:36 -0800 > From: "Garrett D'Amore" > Subject: Re: delete obsolete system call traps [PSARC/2009/657] > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > > > As part of deleting old system call traps from the kernel, > > changes must be made to: > > usr/src/lib/brand/solaris10 > > and: > > usr/src/uts/common/brand/solaris10 > > to emulate the deleted system call traps. > > > > Any process running in a Solaris 10 branded zone will see > > a kernel interface identical to that of Solaris 10 itself. > > Will this change also be made for the Solaris 8 branded zone? > > - Garrett There is no Solaris 8 or Solaris 9 branded zone in Solaris Next. If and when such branded zones come into existence in Solaris Next, then the code for emulating the deleted system calls will necessarily be implemented in them. Roger From gdamore@sun.com Wed Dec 2 17:37:41 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB31bf82006365 for ; Wed, 2 Dec 2009 17:37:41 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB31bfgj002732 for ; Wed, 2 Dec 2009 17:37:41 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB31ba6s018883 for ; Wed, 2 Dec 2009 17:37:36 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU100G00Z606C00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 02 Dec 2009 17:37:35 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU1003P1Z6MGYC0@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 17:37:35 -0800 (PST) Date: Wed, 02 Dec 2009 17:37:34 -0800 From: "Garrett D'Amore" Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-reply-to: <200912030136.nB31aDkJ686325@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Message-id: <4B17165E.1080207@sun.com> References: <200912030136.nB31aDkJ686325@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1199 Roger A. Faulkner wrote: >> Date: Wed, 02 Dec 2009 15:18:36 -0800 >> From: "Garrett D'Amore" >> Subject: Re: delete obsolete system call traps [PSARC/2009/657] >> To: "Roger A. Faulkner" >> Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, >> > Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > >>> As part of deleting old system call traps from the kernel, >>> changes must be made to: >>> usr/src/lib/brand/solaris10 >>> and: >>> usr/src/uts/common/brand/solaris10 >>> to emulate the deleted system call traps. >>> >>> Any process running in a Solaris 10 branded zone will see >>> a kernel interface identical to that of Solaris 10 itself. >>> >> Will this change also be made for the Solaris 8 branded zone? >> >> - Garrett >> > > There is no Solaris 8 or Solaris 9 branded zone in Solaris Next. > If and when such branded zones come into existence in > Solaris Next, then the code for emulating the deleted system > calls will necessarily be implemented in them. > > Roger > I thought that was the case, just wanted to make sure it was explicit. With that, +1. - Garrett From mws@sun.com Thu Dec 3 00:30:23 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB38UNE8028035 for ; Thu, 3 Dec 2009 00:30:23 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB38UN7u005983 for ; Thu, 3 Dec 2009 00:30:23 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB38UIun026695 for ; Thu, 3 Dec 2009 00:30:18 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU200100I75XM00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Thu, 03 Dec 2009 00:30:18 -0800 (PST) Received: from 172.16.1.38 (adsl-75-61-132-87.dsl.pltn13.sbcglobal.net [75.61.132.87]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU200F33IAAJO90@fe-sfbay-09.sun.com>; Thu, 03 Dec 2009 00:30:12 -0800 (PST) Date: Thu, 03 Dec 2009 00:30:10 -0800 From: Mike Shapiro Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-reply-to: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> Sender: Michael.Shapiro@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Message-id: X-Mailer: Apple Mail (2.1076) References: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> Status: RO Content-Length: 1990 On Dec 2, 2009, at 2:42 PM, Roger A. Faulkner wrote: > I am sponsoring this fast-track case for myself. > > No external/ABI interfaces are changing, so there is no > documentation change. > > The release binding is "minor", > so it can be done in solaris_nevada (Solaris Next, OpenSolaris) > (this will never be back-ported). > > DISCUSSION: ... Roger, I certainly agree some of this is implementation and doesn't matter. And from a technical perspective, because the current DTrace syscall provider advertises the sysent table names and not the sub-coded man page (2) view of system calls (something we intend to rectify someday), we marked those names as Private in our stability mechanism. But from a practical perspective, I'm very uncomfortable with the *at part of this project, whereby extremely well-known fundamental names used extensively by users of DTrace based on long-standing fundamentals like syscall::open:entry just go away, essentially for no benefit. (That is, we don't actually have any pressing need to add 74 new system calls to the OS, to make use of this vast slot reclaiming) It just spuriously breaks people's DTrace scripts for no reason, and makes them harder to rewrite, since the *at variants have more complicated flags and whatnot. It would seem that for those, you can simply put the equivalent wrapper you described in the kernel, rather than libc, thereby achieving the same effect of just making the bugs and code exist in one canonical function. Is there any other benefit only achieved by removing those from the sysent table? If not, my preference would be to leave 'open' and friends alone for now, resolving that with kernel function calls instead. If we reach the point of needing the additional slot entries freed up by those, that work can be done along with a true man(2)- equivalent syscall provider. -Mike --- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/ From casper@holland.sun.com Thu Dec 3 05:27:18 2009 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3DRH5T003009 for ; Thu, 3 Dec 2009 05:27:17 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB3DRDq8019152; Thu, 3 Dec 2009 13:27:13 GMT Message-Id: <200912031327.nB3DRDq8019152@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: Mike Shapiro cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-Reply-To: References: <200912022242.nB2MgkRQ644697@jurassic-x4600.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2009 14:27:13 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 595 >Is there any other benefit only achieved by removing those from the >sysent table? If not, my preference would be to leave 'open' and >friends alone for now, resolving that with kernel function calls >instead. If we reach the point of needing the additional slot entries >freed up by those, that work can be done along with a true man(2)- >equivalent syscall provider. Will this not also disable SunOS 4 binary compatibility? I seem to remember that the binary compatibility runs some old system calls before it starts calling the kernel through the native libraries? Casper From Roger.Faulkner@sun.com Thu Dec 3 09:10:45 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3HAjEO009004 for ; Thu, 3 Dec 2009 09:10:45 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nB3HAjtl865123; Thu, 3 Dec 2009 09:10:45 -0800 (PST) Message-Id: <200912031710.nB3HAjtl865123@jurassic-x4600.sfbay.sun.com> Date: Thu, 3 Dec 2009 09:10:45 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: delete obsolete system call traps [PSARC/2009/657] To: mws@sun.com, Casper.Dik@sun.com Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QVD709cV1+nuYd/+DEScew== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 783 > From: Casper.Dik@sun.com > To: Mike Shapiro > cc: "Roger A. Faulkner" , psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > Subject: Re: delete obsolete system call traps [PSARC/2009/657] > Date: Thu, 03 Dec 2009 14:27:13 +0100 > > > Will this not also disable SunOS 4 binary compatibility? I seem to > remember that the binary compatibility runs some old system calls before > it starts calling the kernel through the native libraries? > > Casper I rebuilt /usr/lib/ld.so (the 4.x dynamic linker) so it works correctly with the modified system call traps. Also the libbc stuff and /usr/4lib/sbcp There is no problem with 4.x binary compatibility. Roger From casper@holland.sun.com Thu Dec 3 09:21:44 2009 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3HLhRV009107 for ; Thu, 3 Dec 2009 09:21:43 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB3HLbic029481; Thu, 3 Dec 2009 17:21:38 GMT Message-Id: <200912031721.nB3HLbic029481@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: "Roger A. Faulkner" cc: mws@sun.com, psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-Reply-To: <200912031710.nB3HAjtl865123@jurassic-x4600.sfbay.sun.com> References: <200912031710.nB3HAjtl865123@jurassic-x4600.sfbay.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2009 18:21:37 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 235 >I rebuilt /usr/lib/ld.so (the 4.x dynamic linker) >so it works correctly with the modified system call traps. >Also the libbc stuff and /usr/4lib/sbcp > >There is no problem with 4.x binary compatibility. Thanks Roger. Casper From Roger.Faulkner@sun.com Thu Dec 3 11:05:15 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3J5F8B011314 for ; Thu, 3 Dec 2009 11:05:15 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nB3J5F3q893572; Thu, 3 Dec 2009 11:05:15 -0800 (PST) Message-Id: <200912031905.nB3J5F3q893572@jurassic-x4600.sfbay.sun.com> Date: Thu, 3 Dec 2009 11:05:15 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: delete obsolete system call traps [PSARC/2009/657] To: mws@sun.com Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xtwbkiG1JxpcmpTPjGGGvQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 3775 > Date: Thu, 03 Dec 2009 00:30:10 -0800 > From: Mike Shapiro > Subject: Re: delete obsolete system call traps [PSARC/2009/657] > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > > I certainly agree some of this is implementation and doesn't matter. > And from a technical perspective, because the current DTrace syscall > provider advertises the sysent table names and not the sub-coded man > page (2) view of system calls (something we intend to rectify > someday), we marked those names as Private in our stability mechanism. Wise. The system call trap interfaces are certainly unstable. The users of dtrace must already know this. > But from a practical perspective, I'm very uncomfortable with the *at > part of this project, whereby extremely well-known fundamental names > used extensively by users of DTrace based on long-standing > fundamentals like syscall::open:entry just go away, essentially for no > benefit. (That is, we don't actually have any pressing need to add 74 > new system calls to the OS, to make use of this vast slot reclaiming) > It just spuriously breaks people's DTrace scripts for no reason, and > makes them harder to rewrite, since the *at variants have more > complicated flags and whatnot. The number of freed-up sysent table entries is a red herring. That's not the importance of the work. > It would seem that for those, you can simply put the equivalent > wrapper you described in the kernel, rather than libc, thereby > achieving the same effect of just making the bugs and code exist in > one canonical function. The kernel wrappers are there right now. The code for the open() system call trap in the kernel just calls the kernel's version of openat(). You are recommending that I do nothing, not even modify libc to use the modern/standard *at() interfaces. > Is there any other benefit only achieved by removing those from the > sysent table? If not, my preference would be to leave 'open' and > friends alone for now, resolving that with kernel function calls > instead. If we reach the point of needing the additional slot entries > freed up by those, that work can be done along with a true man(2)- > equivalent syscall provider. How about truth in advertising? Are you aware that nothing calls the fork() system call trap anymore? The code for fork() and forkall() in libc invokes the forksys() system call trap, even though the fork1() and forkall() system call traps are still there in the kernel. Anyone doing: syscall::fork1 syscall::forkall will be puzzled that they see no forks. Also, in the current system there are two ways to open a file: open(path, oflags, mode) openat(dirfd, path, oflags, mode) (where dirfd can be AT_FDCWD to behave the same as open()) Anyone doing: syscall::open syscall::open64 will miss all of the opens executed via openat(). (tar, cpio, pax, rm, cp/ln/mv, nftw(), attropen(), all call openat()) And the openat() system call trap is currently a subcode of the generalized SYS_fsat system call trap number, so you can't do: syscall::openat syscall::openat64 You would have do do some convoluted operation involving: syscall::fsat* Likewise for all of the subcodes of SYS_fsat: * 0 - openat * 1 - openat64 * 2 - fstatat64 * 3 - fstatat * 4 - fchownat * 5 - unlinkat * 6 - futimesat * 7 - renameat * 8 - faccessat My new code breaks these subcodes out into individual system call traps and eliminates the SYS_fsat trap number, so you can do: syscall::openat syscall::openat64 and likewise for all of the other *at() interfaces. Roger From mws@sun.com Thu Dec 3 11:17:38 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3JHcYh011451 for ; Thu, 3 Dec 2009 11:17:38 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB3JHcia014108 for ; Thu, 3 Dec 2009 11:17:38 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB3JHX9u016934 for ; Thu, 3 Dec 2009 11:17:33 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU300A00B33U800@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Thu, 03 Dec 2009 11:17:33 -0800 (PST) Received: from [10.0.216.107] ([unknown] [129.150.241.212]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU3007H9C8T5360@fe-sfbay-09.sun.com>; Thu, 03 Dec 2009 11:17:17 -0800 (PST) Date: Thu, 03 Dec 2009 11:17:16 -0800 From: Mike Shapiro Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-reply-to: <200912031905.nB3J5F3q893572@jurassic-x4600.sfbay.sun.com> Sender: Michael.Shapiro@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Message-id: <44655CC4-05CD-4A5C-AEB9-AA423A29BD4B@sun.com> X-Mailer: Apple Mail (2.1076) References: <200912031905.nB3J5F3q893572@jurassic-x4600.sfbay.sun.com> Status: RO Content-Length: 2840 > The kernel wrappers are there right now. > The code for the open() system call trap in the kernel > just calls the kernel's version of openat(). > You are recommending that I do nothing, not even > modify libc to use the modern/standard *at() interfaces. No, I was recommending that for "open" and perhaps any other extremely well-known thing we leave the sysent thing and the kernel wrapper and not do that in libc. But see below. > >> Is there any other benefit only achieved by removing those from the >> sysent table? If not, my preference would be to leave 'open' and >> friends alone for now, resolving that with kernel function calls >> instead. If we reach the point of needing the additional slot >> entries >> freed up by those, that work can be done along with a true man(2)- >> equivalent syscall provider. > > How about truth in advertising? We have that, that's why we do only what is in the sysent table, and don't have aliases and illusions. The only ways to do this are to either describe the sysent table as it is (what we do now), or to describe the provider as the set of syscalls in section (2) man pages (what we hope to do in the grand fullness of time, as I described in the previous e-mail). > Are you aware that nothing calls the fork() system call trap anymore? > The code for fork() and forkall() in libc invokes the forksys() system > call trap, even though the fork1() and forkall() system call traps are > still there in the kernel. Anyone doing: > syscall::fork1 > syscall::forkall > will be puzzled that they see no forks. Yes, we know. > Also, in the current system there are two ways to open a file: > open(path, oflags, mode) > openat(dirfd, path, oflags, mode) > (where dirfd can be AT_FDCWD to behave the same as open()) > Anyone doing: > syscall::open > syscall::open64 > will miss all of the opens executed via openat(). > (tar, cpio, pax, rm, cp/ln/mv, nftw(), attropen(), all call openat()) > > And the openat() system call trap is currently a subcode of the > generalized SYS_fsat system call trap number, so you can't do: > syscall::openat > syscall::openat64 > You would have do do some convoluted operation involving: > syscall::fsat* > > Likewise for all of the subcodes of SYS_fsat: > * 0 - openat > * 1 - openat64 > * 2 - fstatat64 > * 3 - fstatat > * 4 - fchownat > * 5 - unlinkat > * 6 - futimesat > * 7 - renameat > * 8 - faccessat > > My new code breaks these subcodes out into individual system call > traps and eliminates the SYS_fsat trap number, so you can do: > syscall::openat > syscall::openat64 > and likewise for all of the other *at() interfaces. > > Roger That's certainly an improvement, given the current state of things. -Mike --- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/ From gww@sac.sfbay.sun.com Thu Dec 3 11:34:28 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3JYSk5011720; Thu, 3 Dec 2009 11:34:28 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB3JYSqn011719; Thu, 3 Dec 2009 11:34:28 -0800 (PST) Date: Thu, 3 Dec 2009 11:34:28 -0800 (PST) From: Gary Winiger Message-Id: <200912031934.nB3JYSqn011719@sac.sfbay.sun.com> To: Roger.Faulkner@sun.com, psarc-ext@sac.sfbay.sun.com Cc: Bart.Smaalders@sun.com, bryan.cantrill@sun.com, darrin.johnson@sun.com, michael.shapiro@sun.com Subject: Re: delete obsolete system call traps [PSARC/2009/657] Status: RO Content-Length: 364 > I am sponsoring this fast-track case for myself. > > No external/ABI interfaces are changing, so there is no documentation change. I don't see any mention of how Solaris Audit will be affected. I've not looked at the current implementation to see how each of the current syscalls maps into audit events. Are all the current audit events preserved? Gary.. From Roger.Faulkner@sun.com Thu Dec 3 14:07:46 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB3M7kj0016158; Thu, 3 Dec 2009 14:07:46 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nB3M7jxb169871; Thu, 3 Dec 2009 14:07:45 -0800 (PST) Message-Id: <200912032207.nB3M7jxb169871@jurassic-x4600.sfbay.sun.com> Date: Thu, 3 Dec 2009 14:07:45 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: delete obsolete system call traps [PSARC/2009/657] To: psarc-ext@sac.sfbay.sun.com, gww@sac.sfbay.sun.com Cc: Bart.Smaalders@sun.com, bryan.cantrill@sun.com, darrin.johnson@sun.com, michael.shapiro@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0BTWNxUg4Ki1Al+1KM0LRg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 820 > Date: Thu, 3 Dec 2009 11:34:28 -0800 (PST) > From: Gary Winiger > To: Roger.Faulkner@sun.com, psarc-ext@sac.sfbay.sun.com > Cc: Bart.Smaalders@sun.com, bryan.cantrill@sun.com, darrin.johnson@sun.com, michael.shapiro@sun.com > Subject: Re: delete obsolete system call traps [PSARC/2009/657] > > > I am sponsoring this fast-track case for myself. > > > > No external/ABI interfaces are changing, so there is no documentation change. > > I don't see any mention of how Solaris Audit will be affected. > I've not looked at the current implementation to see how each > of the current syscalls maps into audit events. > Are all the current audit events preserved? I believe so. I modified the audit code as best I knew how. I'll need an audit expert to review the code. Volunteer? Roger From Roger.Faulkner@sun.com Tue Dec 15 11:01:57 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFJ1uQZ017569 for ; Tue, 15 Dec 2009 11:01:56 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id nBFJ1uIQ348520; Tue, 15 Dec 2009 11:01:56 -0800 (PST) Message-Id: <200912151901.nBFJ1uIQ348520@jurassic-x4600.sfbay.sun.com> Date: Tue, 15 Dec 2009 11:01:56 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: delete obsolete system call traps [PSARC/2009/657] To: psarc-ext@sac.sfbay.sun.com Cc: Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iTYfh302WPU7+k1XGKg9tA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_124 SunOS 5.11 i86pc i386 Status: RO Content-Length: 3032 > Date: Thu, 03 Dec 2009 00:30:10 -0800 > From: Mike Shapiro > Subject: Re: delete obsolete system call traps [PSARC/2009/657] > To: "Roger A. Faulkner" > Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > ... > I certainly agree some of this is implementation and doesn't matter. > And from a technical perspective, because the current DTrace syscall > provider advertises the sysent table names and not the sub-coded man > page (2) view of system calls (something we intend to rectify > someday), we marked those names as Private in our stability mechanism. > > But from a practical perspective, I'm very uncomfortable with the *at > part of this project, whereby extremely well-known fundamental names > used extensively by users of DTrace based on long-standing > fundamentals like syscall::open:entry just go away, essentially for no > benefit. I discussed this matter offline with Michael Shapiro and Bryan Cantrill. While it is unfortunate that the current DTrace syscall provider has caused the syscall trap table to have become a public interface, DTrace usage is widespread enough to warrent keeping unchanged what Mike refers to as "extremely well-known fundamental names used extensively by users of DTrace based on long-standing fundamentals like syscall::open:entry". This not a tenable long-term solution. The kernel <-> user-level syscall trap interface has never been a Solaris public interface. The long-term solution is to implement what Mike refers to as "the sub-coded man page (2) view of system calls" in the DTrace syscall provider. In the interim, for the current PSARC case for deleting obsolete system call traps, I am changing the proposal as follows: =========================================================== Retain these old system call traps; make sure they are called from libc as always so that existing DTrace scripts continue to work as always: open() open64() stat() lstat() fstat() stat64() lstat64() fstat64() rename() unlink() rmdir() chown() lchown() fchown() access() Delete these in favor of open*(path, O_WRONLY | O_CREAT | O_TRUNC, mode): creat() creat64() Delete this in favor of fcntl(F_DUPFD): dup() Delete these from i386 code in favor of *stat() amd mknod() (they should have been deleted when COFF support was dropped): _xstat() _lxstat() _fxstat() _xmknod() Delete these (they are never called from libc): exec() fork1() forkall() poll() utime() utimes() umount() wait() lwp_mutex_lock() lwp_sema_wait() Delete this: fsat() in favor of individual (new) system call traps for each of its subcodes: openat() openat64() fstatat() fstatat64() renameat() unlinkat() fchownat() faccessat() =========================================================== Roger Faulkner From gdamore@sun.com Tue Dec 15 11:17:12 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFJHC7g017859 for ; Tue, 15 Dec 2009 11:17:12 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFJHCf7022129 for ; Tue, 15 Dec 2009 11:17:12 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBFJH7ru010400 for ; Tue, 15 Dec 2009 11:17:07 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUP00900K3YDF00@fe-sfbay-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Tue, 15 Dec 2009 11:17:07 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUP003JSK8I4UG0@fe-sfbay-09.sun.com>; Tue, 15 Dec 2009 11:17:07 -0800 (PST) Date: Tue, 15 Dec 2009 11:17:05 -0800 From: "Garrett D'Amore" Subject: Re: delete obsolete system call traps [PSARC/2009/657] In-reply-to: <200912151901.nBFJ1uIQ348520@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com Message-id: <4B27E0B1.8090707@sun.com> References: <200912151901.nBFJ1uIQ348520@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 3323 Looks good to me. +1 on this revised specification. - Garrett Roger A. Faulkner wrote: >> Date: Thu, 03 Dec 2009 00:30:10 -0800 >> From: Mike Shapiro >> Subject: Re: delete obsolete system call traps [PSARC/2009/657] >> To: "Roger A. Faulkner" >> Cc: psarc-ext@sac.sfbay.sun.com, Bart.Smaalders@sun.com, >> > Bryan.Cantrill@sun.com, Michael.Shapiro@sun.com, Darrin.Johnson@sun.com > > ... > >> I certainly agree some of this is implementation and doesn't matter. >> And from a technical perspective, because the current DTrace syscall >> provider advertises the sysent table names and not the sub-coded man >> page (2) view of system calls (something we intend to rectify >> someday), we marked those names as Private in our stability mechanism. >> >> But from a practical perspective, I'm very uncomfortable with the *at >> part of this project, whereby extremely well-known fundamental names >> used extensively by users of DTrace based on long-standing >> fundamentals like syscall::open:entry just go away, essentially for no >> benefit. >> > > I discussed this matter offline with Michael Shapiro and Bryan Cantrill. > > While it is unfortunate that the current DTrace syscall provider > has caused the syscall trap table to have become a public interface, > DTrace usage is widespread enough to warrent keeping unchanged what > Mike refers to as "extremely well-known fundamental names used > extensively by users of DTrace based on long-standing fundamentals > like syscall::open:entry". > > This not a tenable long-term solution. The kernel <-> user-level > syscall trap interface has never been a Solaris public interface. > The long-term solution is to implement what Mike refers to as > "the sub-coded man page (2) view of system calls" in the DTrace > syscall provider. > > In the interim, for the current PSARC case for deleting obsolete > system call traps, I am changing the proposal as follows: > > =========================================================== > > Retain these old system call traps; > make sure they are called from libc as always so that > existing DTrace scripts continue to work as always: > open() > open64() > stat() > lstat() > fstat() > stat64() > lstat64() > fstat64() > rename() > unlink() > rmdir() > chown() > lchown() > fchown() > access() > > Delete these in favor of open*(path, O_WRONLY | O_CREAT | O_TRUNC, mode): > creat() > creat64() > > Delete this in favor of fcntl(F_DUPFD): > dup() > > Delete these from i386 code in favor of *stat() amd mknod() > (they should have been deleted when COFF support was dropped): > _xstat() > _lxstat() > _fxstat() > _xmknod() > > Delete these (they are never called from libc): > exec() > fork1() > forkall() > poll() > utime() > utimes() > umount() > wait() > lwp_mutex_lock() > lwp_sema_wait() > > Delete this: > fsat() > in favor of individual (new) system call traps for each of its subcodes: > openat() > openat64() > fstatat() > fstatat64() > renameat() > unlinkat() > fchownat() > faccessat() > > =========================================================== > > Roger Faulkner > > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Dec 16 04:15:07 2009 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBGCF7f1017756 for ; Wed, 16 Dec 2009 04:15:07 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBGCF7R2009877 for ; Wed, 16 Dec 2009 04:15:07 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBGC5g3R018553 for ; Wed, 16 Dec 2009 12:15:07 GMT Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-4761968 for psarc-ext@sac.sfbay.sun.com; Wed, 16 Dec 2009 12:15:01 Z Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-345688 for psarc-ext@sac.sfbay.sun.com; Wed, 16 Dec 2009 12:14:59 Z Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-12906525 for psarc-ext@sac.sfbay.sun.com; Wed, 16 Dec 2009 12:14:59 Z Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id DD2689408E; Wed, 16 Dec 2009 13:14:57 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id DD6E494086; Wed, 16 Dec 2009 13:14:52 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id nBGCEqIZ006898; Wed, 16 Dec 2009 13:14:53 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 13:14:52 +0100 Date: Wed, 16 Dec 2009 13:14:52 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: Roger.Faulkner@sun.com, psarc-ext@sac.sfbay.sun.com Cc: Michael.Shapiro@sun.com, Darrin.Johnson@sun.com, Bryan.Cantrill@sun.com, Bart.Smaalders@sun.com Subject: Re: delete obsolete system call traps [PSARC/2009/657] Message-ID: <4b28cf3c.881nuywlyKoKjFsp%Joerg.Schilling@fokus.fraunhofer.de> References: <200912151901.nBFJ1uIQ348520@jurassic-x4600.sfbay.sun.com> In-Reply-To: <200912151901.nBFJ1uIQ348520@jurassic-x4600.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 16 Dec 2009 12:14:52.0779 (UTC) FILETIME=[5F2A23B0:01CA7E49] X-Antispam: No, score=0.0/5.0, scanned in 1.630sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Status: RO Content-Length: 1680 "Roger A. Faulkner" wrote: > =========================================================== > > Retain these old system call traps; > make sure they are called from libc as always so that > existing DTrace scripts continue to work as always: > open() > open64() > stat() > lstat() > fstat() > stat64() > lstat64() > fstat64() > rename() > unlink() > rmdir() > chown() > lchown() > fchown() > access() > > Delete these in favor of open*(path, O_WRONLY | O_CREAT | O_TRUNC, mode): > creat() > creat64() > > Delete this in favor of fcntl(F_DUPFD): > dup() > > Delete these from i386 code in favor of *stat() amd mknod() > (they should have been deleted when COFF support was dropped): > _xstat() > _lxstat() > _fxstat() > _xmknod() > > Delete these (they are never called from libc): > exec() > fork1() > forkall() > poll() > utime() > utimes() > umount() > wait() > lwp_mutex_lock() > lwp_sema_wait() > > Delete this: > fsat() > in favor of individual (new) system call traps for each of its subcodes: > openat() > openat64() > fstatat() > fstatat64() > renameat() > unlinkat() > fchownat() > faccessat() > > =========================================================== This revised plan looks OK. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily