From Thu Oct 6 14:11:39 2005 Date: Thu, 6 Oct 2005 14:11:39 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 1128633099 24 Delete. This is a system message. --END+PSEUDO-- From sacadmin Thu Jun 10 09:13:33 2004 Date: Thu, 10 Jun 2004 10:12:20 -0600 From: Andy Rudoff Subject: PSARC/2004/480: star To: psarc@sac.eng.sun.com Cc: Dworkin Muller MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502) Content-Length: 11123 Status: RO X-Status: $$$$ X-UID: 0000000001 I'm sponsoring this fast-track for Dworking Muller, timeout 06/17/2004. -andy ================================================================ 1. Introduction 1.1. Project/Component Working Name: Schilly/standard tar PSARC FastTrack, proposed timeout 06/17/2004 Case Number: PSARC/2004/480 1.2. Name of Document Author/Supplier: Author: Dworkin Müller Sponsor: Andy Rudoff 1.3 Date of This Document: June 9, 2004 4. Technical Description Executive Summary It is proposed that we incorporate Jörg Schilling's star package into the SFW consolidation, installing some parts into /usr/sfw and others into /usr. The primary motivator is getting the remote tape daemon (rmt) portion, which is significantly faster, much less buggy, and supports non-Sun clients far better than the existing Solaris version does. Once star supports all of the features of Sun's tar, also replacing our tar with star for improved performance and better standards conformance. Finally, librmt makes it easy to convert any utility that accesses local devices to also being able to access remote devices. Background The star package has been under development by Jörg Schilling since 1982. The design goals have always been performance and standards compliance (once there were standards to comply with). It consists of the programs rmt, star, and mt, and the library librmt. These are each described below in more detail. As a whole, rmt and star achieve significantly better throughput than their Solaris equivalents (/usr/sbin/rmt and /usr/sbin/tar), such that they are capable of keeping modern tape drives constantly streaming. and generally being limited by physical device speeds. That and their significantly better interoperability in a hetergeneous environment as well as better standards compliance are the main motivators for bringing them in. rmt(1M) provides remote systems access to a local machine's storage resources, primarily tape drives. It differs from NFS, ``rsh cat'', and the like in that it has a request/response protocol geared specifically towards the needs of programs using tape drives (e.g., direct support for the MTIOCGET ioctl(2), doing i/o operations in the block sizes required by the remote program, etc). The problems with the current rmt are that: - it is slow - it is moderately buggy - the documentation is noticeably out-of-sync with the code - it has no concept of security beyond what the system itself enforces (i.e., if you can get it running as root, you can read or write any file on the machine) Schilling's version of rmt is compatible with all of the protocol extensions that Sun has made relative to the original Berkeley implementation, as well as those made by GNU. It has been benchmarked to provide up to at least a 40% throughput improvement. Thus, it is a drop-in replacement whose main visible effect is improved throughput (especially when combined with librmt, below). The other customer-visible difference would be that it comes with a configuration file (/etc/default/rmt) that allows restricting individual users of rmt to specific devices and/or hosts. Sun has a not-quite-a-library, rmtlib, that is not actually shipped to customers. It exists in our source tree as usr/src/cmd/backup/lib/rmtlib.c, and as that implies, is statically linked into ufsdump and ufsrestore. It has the bare minimum functionality required by those utilities, and has several bugs besides being slow. Fortunately, most of problems are harmless as far as ufsdump and ufsrestore are concerned, but general clients would have problems using this library. This is of concern because utilities such as tar, cpio, and mt really ought to be able to use remote tapes as well as local ones. Star's librmt is a complete client library for applications to interact with an rmt daemon running on a remote tape host - a complete version of what the Solaris rmtlib is an attempt at. It does not depend on the remote rmt being the same as the one that comes with star - any rmt that supports at least the core protocol originally defined at Berkeley will work. Besides performance and generality improvements, one major feature is that it supports the use of an environment variable (RSH) whose value is the path of a program to use to communicate with the remote host instead of the traditional rcmd(3c). The program has to have the same usage synopsis as rsh(1); for sites that have concern about privacy, the usual value for RSH is /usr/local/bin/ssh. By including librmt in the Solaris operating system and switching ufsdump and ufsrestore over to using it, we would be able to trivially satisfy RFE 4432948. Since nothing else uses rmtlib, it doesn't really need to be a drop-in replacement. The mt program in star is logically equivalent to the Solaris version, but there are a handful of Sun-specific features that are not present in the star version. At this time, it is not proposed that the Solaris mt be replaced. Schilling suggested either that we just link our mt with his librmt, or make our mt open source so that he could put the missing features into his. The proposal at this time is to go with the former, so as to reduce the number of non-technical complications. Finally, there is star itself, fully named ``Schilly tar'' or more recently ``standard tar''. The latter refers to star's full POSIX compliance. It is a functional superset of most versions of tar(1) that are available on various operating systems. That, the compliance, and significantly greater throughput than the Solaris tar are the main items of interest. For perspective, note that most of the externally-found bugs in the Solaris tar were found using the test suite that comes with star. Star, of course, passes those tests. Unfortunately, star is not a drop-in replacement for Solaris tar. In particular, it does not provide these features: -e exit immediately upon unexpected error (if envar SYSV3 set, do not split files across volumes) -E use extended headers; this functionality exists in star, but not using this argument -k yy archive/volume size - uses this instead of whatever size the media actually is -n not reading from tape, so can use random seeks -P suppress adding trailing / on directory entries in the archive -q stop after extracting first instance of requested file -X yy exclude files named in the file yy -@ included Sun extended attributes in the archive With the exception of -@, all of these would be trivial to add (and Schillling is quite likely to do so if we start shipping star). The command line synopsis is far more general than tar's. Although it can be used according to Sun's CLI standard, it goes beyond what is prescribed there in some respects. For the extended attributes support, he has indicated that he would need some guidance (preferably by seeing the source) as to how they were done so he could do the equivalent in star. The code bases are sufficiently different that copying the code would not be useful/likely; simply giving a clear description of the archive format changes may be sufficient. The original impetus for this fast-track is RFE 4496994, which was filed in response to a request from Schilling to include his rmt in the Solaris operating system. In subsequent discussion, the scope expanded from rmt to all of star, and he has indicated a desire to retain ownership (not exactly a surprise). He has also said that he would like to get Sun's (aka PSARC's) blessing on any future protocol changes that may come up. The open source legal review for star has been successfully passed - although star is distributed to the world at large under the GPL, Schilling is providing Sun with a BSD-derived license. The main open question at this time is how much can we show/tell him of existing code to help with implementing features in the Solaris mt and tar that are not in the star equivalents. Impact on a Solaris Installation The following changes would result from the initial integration of star into the SFW consolidation: - /usr/sbin/rmt executable from ON replaced by the rmt from star - /etc/default/rmt configuration file added (defaults to full access) - /usr/lib/librmt.so.1 shared library added - /usr/lib/librmt.so symlink to librmt.so.1 added - /usr/sfw/sbin/star executable added - /usr/sfw/sbin/ustar symlink to star added - usr/src/cmd/rmt removed from ON build and/or deleted - usr/src/cmd/backup/lib substantially trimmed - usr/src/cmd/backup/ufs{dump,restore} modified to link with the new librmt - man page modifications as dictated by SFW and Tech Pubs guidelines Anticipated future changes: - usr/src/cmd/cpio modified to link with librmt - usr/src/cmd/mt modified to link with librmt - either usr/src/cmd/tar modified to link with librmt, or star augmented to be a full replacement for the existing Solaris tar. If the latter is done, usr/src/cmd/tar would be removed from ON and the binary replaced with a symlink to the star executable. At that time, star and ustar may also move from /usr/sfw/sbin to /usr/sbin. The constraints leading to the mixed installation targets are: - The path ``/etc/rmt'' has to resolve to the intended rmt executable. Currently, it is a symlink to /usr/sbin/rmt. The installation process for /usr/sfw could change that symlink to something like /usr/sfw/sbin/rmt if it is installing star (or even just rmt). However... - To have ufsdump and ufsrestore link with librmt, that library needs to be guaranteed to be available. - One of the main purposes of this effort is to improve our reliability and performance out of the box. Making star, rmt, and librmt be completely optional negates that effort. Support requirements Most work on star will continue to be done by Schilling. The bulk of our investment will be the initial conversion to the SFW build environment, and possibly adding internationalization support (gettext()). Once that is done, most future future updates can be applied via patch(1). We have been asked to give back changes as appropriate, so some degree of review for such things will be necessary. The expected give-backs are internationalization and some amount of help implementing extended attribute support. Exactly how much of the latter may occur is still being discussed with the legal department. Targeted Releases This is primarily intended for s10, but at this point it is much more likely to end up in s11 with a backport to an s10 update release. We would also like to have the option of putting it into an s9 update release. Everything is strictly backwards compatible, so a patch binding seems appropriate. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack From sacadmin Thu Jun 10 09:25:05 2004 Date: Thu, 10 Jun 2004 09:24:31 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com, Andy.Rudoff@sun.com Cc: Dworkin.Muller@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QOF87CXxmfIICU+N4KE8ZA== Content-Length: 336 Status: RO X-Status: $$$$ X-UID: 0000000002 I didn't see interface commitment levels in this. It seems like an interesting combination of stable (rmt) and external. Could the submitter put a stake in the sand for this? It strikes me that this might just be better off going the full 9 yards to stable and ignoring the swf moniker. (Just something to be considered.) - jek3 From sacadmin Thu Jun 10 10:47:34 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 11:44:38 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 1634 Status: RO X-Status: $$$$ X-UID: 0000000003 Joseph E. Kowalski III writes: : I didn't see interface commitment levels in this. It seems like an : interesting combination of stable (rmt) and external. Could the submitter : put a stake in the sand for this? Looks like it got dropped accidentally during one of the edit cycles. As far as rmt is concerned, ``stable'' is probably most appropriate, but see below. In the greater context of star, we can certainly classify the ANSI-compliant part that way, but there are quite a few extensions there as well (all of which have to be turned on by the user). : It strikes me that this might just be better off going the full 9 yards : to stable and ignoring the swf moniker. (Just something to be considered.) That was my initial inclination as well. Someone (I can't remember who) convinced me that that had the potential of being far more pain than the advantage would provide. The gist of the argument was that making it be ON-compliant would require things like full internationalization, Makefile rewriting, etc, and that would need to be redone (or least carefully reviewed) every time we got an update from Joerg. Now, I fully admit that the interaction between commitment level, consolidation, and so on confuses me, so if stable still allows being in the SFW consolidation, that'd be ideal. Purely from a technical standpoint, the rmt protocol is very definitely stable. It gets added to very occasionally, but by its nature existing messages can't really be changed. There are too many different platforms out there that support some (often quite old) variant, which gives us a de facto standard. Dworkin From sacadmin Thu Jun 10 11:49:02 2004 Date: Thu, 10 Jun 2004 11:48:29 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com, Dworkin.Muller@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IXPc42PZYnRseE0NQ3yQQQ== Content-Length: 2403 Status: RO X-Status: $$$$ X-UID: 0000000004 > From: Dworkin Muller ... > Joseph E. Kowalski III writes: > : I didn't see interface commitment levels in this. It seems like an > : interesting combination of stable (rmt) and external. Could the submitter > : put a stake in the sand for this? > > Looks like it got dropped accidentally during one of the edit cycles. > As far as rmt is concerned, ``stable'' is probably most appropriate, > but see below. In the greater context of star, we can certainly > classify the ANSI-compliant part that way, but there are quite a few > extensions there as well (all of which have to be turned on by the > user). Humm, the ANSI part could be "Standard". The extra bells and whissles could be "stable", "external" or disabled. > : It strikes me that this might just be better off going the full 9 yards > : to stable and ignoring the swf moniker. (Just something to be considered.) > > That was my initial inclination as well. Someone (I can't remember > who) convinced me that that had the potential of being far more pain > than the advantage would provide. The gist of the argument was that > making it be ON-compliant would require things like full > internationalization, Makefile rewriting, etc, and that would need to > be redone (or least carefully reviewed) every time we got an update > from Joerg. Several issues are being crossed here. The installation location and the delivering consolidation are separable. However, this only "solves" your makefile rewriting problem. /usr/sbin/rmt *does not* have the option of being external (because of where it is installed). Hence, it will need the i18n and full support anyway. > Now, I fully admit that the interaction between commitment level, > consolidation, and so on confuses me, so if stable still allows being > in the SFW consolidation, that'd be ideal. It does, but as above it only frees you from the internal build rules. It does not free you from the big rules of i18n and the "Solaris Application Binary Guarentee" (ie: never an incompatable change). > Purely from a technical standpoint, the rmt protocol is very > definitely stable. It gets added to very occasionally, but by its > nature existing messages can't really be changed. There are too many > different platforms out there that support some (often quite old) > variant, which gives us a de facto standard. > > Dworkin - jek3 From sacadmin Thu Jun 10 12:06:31 2004 Date: Thu, 10 Jun 2004 20:05:52 +0100 (BST) From: Andrew Gabriel Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com, Dworkin.Muller@Sun.COM, Joseph.Kowalski@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6C4kWq3Jgyb568TBlheQIA== Content-Length: 913 Status: RO X-Status: $$$$ X-UID: 0000000005 > Several issues are being crossed here. > > The installation location and the delivering consolidation are separable. > However, this only "solves" your makefile rewriting problem. > > /usr/sbin/rmt *does not* have the option of being external (because of > where it is installed). Hence, it will need the i18n and full support > anyway. If I understand rmt(1M) correctly, it is never invoked directly from the command line, and it doesn't have any human interface. It should probably have never been in /usr/sbin anyway, but rather somewhere in /usr/lib. I believe it is always invoked as /etc/rmt, which could presumably point somewhere else if the need arose and it was thought desirable. However, I could be wrong on one or more of these points. One unrelated question -- how compatible would be a ufsdump using the new rmtlib be with an older system running our /usr/sbin/rmt ? -- Andrew Gabriel From sacadmin Thu Jun 10 12:12:04 2004 Date: Thu, 10 Jun 2004 12:11:31 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com, Dworkin.Muller@Sun.COM, Joseph.Kowalski@eng.sun.com, Andrew.Gabriel@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vkdLnlU7ggPqmIPrR3ySWA== Content-Length: 678 Status: RO X-Status: $$$$ X-UID: 0000000006 > From: Andrew Gabriel ... > If I understand rmt(1M) correctly, it is never invoked directly > from the command line, and it doesn't have any human interface. > It should probably have never been in /usr/sbin anyway, but > rather somewhere in /usr/lib. I believe it is always invoked > as /etc/rmt, which could presumably point somewhere else if the > need arose and it was thought desirable. I assert that: /etc/rmt is just as bad as /usr/sbin/rmt. It's *not* /usr/sfw ... I could be argued with because we've said that external stuff is welcome to have configuration files in /etc, but I think the high order bit here is "executable". - jek3 From sacadmin Thu Jun 10 12:28:21 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 15:27:45 -0400 From: James Carlson To: "Joseph E. Kowalski III" Cc: psarc@sac.eng.sun.com, Dworkin.Muller@Sun.COM, Andrew.Gabriel@Sun.COM Subject: Re: PSARC/2004/480: star Content-Length: 1191 Status: RO X-Status: $$$$ X-UID: 0000000007 Joseph E. Kowalski III writes: > /etc/rmt is just as bad as /usr/sbin/rmt. It's *not* /usr/sfw ... > > I could be argued with because we've said that external stuff is welcome > to have configuration files in /etc, but I think the high order bit here > is "executable". I think that misses the point. The "interface" is the on-the-wire protocol that actually invokes 'rmt'. That interface expects that spitting the string "/etc/rmt" into a remote shell will invoke the daemon-side implementation of the remote tape interface. For example, see: $SRC/cmd/backup/lib/rmtlib.c in ON. We could never actually move that link out of /etc, because _other_ existing, already-deployed systems depend on it in order to work properly. Similary, some systems have it in /usr/sbin/rmt (it seems to be there on AIX), and others have it in both places (such as BSD). Anyway, it's not an administrative interface, so the rules for administrative interfaces shouldn't apply. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Jun 10 13:37:31 2004 From: Bill Sommerfeld To: Andy Rudoff cc: psarc@sac.eng.sun.com, Dworkin Muller Subject: Re: PSARC/2004/480: star Date: Thu, 10 Jun 2004 16:36:58 -0400 Content-Length: 212 Status: RO X-Status: $$$$ X-UID: 0000000008 > for sites that have concern about privacy, the usual value for > RSH is /usr/local/bin/ssh. nit: on OS's (including solaris since s9) which have ssh integrated, you probably mean /usr/bin/ssh. - Bill From sacadmin Thu Jun 10 14:45:06 2004 Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: psarc@sac.eng.sun.com, Dworkin Muller From: Allen Wittenauer Subject: Re: PSARC/2004/480: star Date: Thu, 10 Jun 2004 14:44:33 -0700 To: Andy Rudoff Content-Length: 571 Status: RO X-Status: $$$$ X-UID: 0000000009 On Jun 10, 2004, at 9:12 AM, Andy Rudoff wrote: > Finally, there is star itself, fully named ``Schilly tar'' or > more recently ``standard tar''. The latter refers to star's > full POSIX compliance. It is a functional superset of most > versions of tar(1) that are available on various operating > systems. That, the compliance, and significantly greater > throughput than the Solaris tar are the main items of > interest. How does star handle tar files embedded with long filenames? i.e., will users still have to rely on GNU tar for this functionality? From sacadmin Thu Jun 10 15:00:42 2004 Date: Thu, 10 Jun 2004 22:56:10 +0100 (BST) From: Andrew Gabriel Subject: Re: PSARC/2004/480: star To: Andy.Rudoff@sun.com, allenw@sun.com Cc: psarc@sac.eng.sun.com, Dworkin.Muller@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: RTYnLEqcaaP1Lzb3piX7kQ== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id i5AM0gJK005344 Content-Length: 631 Status: RO X-Status: $$$$ X-UID: 0000000010 Allen Wittenauer wrote: > How does star handle tar files embedded with long filenames? i.e., >will users still have to rely on GNU tar for this functionality? If you are referring to the ~100 character boundary, star copes with that. There have been lots of tar versions around which create broken archives around this 100 character boundary (GNU tar has been one of the worst historically), and star actually manages to recover many of these broken archives correctly, even when the tar that created them can't. [This response is based on conversations I've had with Jörg in the past.] -- Andrew Gabriel From sacadmin Thu Jun 10 15:09:08 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 16:06:14 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 4658 Status: RO X-Status: $$$$ X-UID: 0000000011 jk: Joseph E. Kowalski III ag: Andrew Gabriel jc: James Carlson jk: Humm, the ANSI part could be "Standard". The extra bells and whissles jk: could be "stable", "external" or disabled. Standard+external sounds like the right mix. I suspect we'd get lots of negative response if we turned off large parts of star.... jk: It does, but as above it only frees you from the internal build rules. jk: It does not free you from the big rules of i18n and the "Solaris jk: Application Binary Guarentee" (ie: never an incompatable change). I18n for rmt and librmt is actually an interesting little conundrum, because rmt likely isn't running on the system that its client is on. There's nothing to stop someone from, say, running ufsdump in Menlo Park and having it write to a tape in Beijing. Error messages are returned both as numeric errnos (which are demonstrably non-portable across systems) and text strings. Seems like you'd want the translation done on the client (aka in librmt), but since there's no guarantee of exactly what text you'll get out of the far end (it could be running just about any OS after all), setting up a complete catalog is difficult. ag: If I understand rmt(1M) correctly, it is never invoked directly ag: from the command line, and it doesn't have any human interface. Correct. Per the above, my intention has been to not worry about i18n in rmt itself. When librmt gets brought in, I'd set it up with a catalog of the strings that we expect out of the various historical versions of the Solaris rmt, the new Schillling rmt, and our current errno string table. I suppose true completeness would say that any historical variants on the errno strings should be included as well, but that seems a little overkill. ag: It should probably have never been in /usr/sbin anyway, but ag: rather somewhere in /usr/lib. I believe it is always invoked ag: as /etc/rmt, which could presumably point somewhere else if the ag: need arose and it was thought desirable. ag: ag: However, I could be wrong on one or more of these points. You are completely correct as far as you go. Originally, the binary lived in /etc/rmt (at Berkeley and I'm pretty sure Sunos 3.x; certainly in earlier releases). There was a big push to make / as small as possible in Sunos 4.x, so it got moved from /etc to /usr/etc and a symlink dropped in. I'm not sure when it moved from /usr/etc to /usr/sbin, but the SCCS history suggests it was put there as part of the original SVr4/5.0 work. ag: One unrelated question -- how compatible would be a ufsdump using ag: the new rmtlib be with an older system running our /usr/sbin/rmt ? Completely. The bulk of the Schilling rmt extensions boil down to supporting our extensions to the protocol (which date back to the Harpy project, ~5.3). There is a handshake done at the beginning of the connection that determines whether or not the extensions are supported by the rmt daemon. If/when any more protocol changes are needed (I don't believe any are being contemplated at the moment), one additional one will be to add an explicit version number to that handshake. Right now, it's simply an attempt at a known-bad ioctl(), and the success/failure of it indicates which kind of rmt we're talking to. jc: The "interface" is the on-the-wire jc: protocol that actually invokes 'rmt'. That interface expects that jc: spitting the string "/etc/rmt" into a remote shell will invoke the jc: daemon-side implementation of the remote tape interface. jc: [...] jc: We could never actually move that link out of /etc, because _other_ jc: existing, already-deployed systems depend on it in order to work jc: properly. Correct. That was set down in the early BSD releases, and anyone who used that as an original code base is stuck with it. The name /etc/rmt is a de facto standard. Where the binary actually lives, of course, is totally independent of that name, as long as that name gets you to the program. One nit: it's actually rcmd(3SOCKET), not rsh(1M). The latter does all sorts of obnoxious buffering that doesn't play at all well with request/response protocols. That's a lot of why we've never supported external transports like ssh - if we were using rsh already, changing what we exec(2) based on an envar would be trivial. jc: Anyway, it's not an administrative interface, so the rules for jc: administrative interfaces shouldn't apply. As far as rmt is concerned, this is my feeling as well. As far as anything else in the star package goes, all of the concerns about i18n, paths, etc seem dead on. Dworkin From sacadmin Thu Jun 10 15:11:12 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 16:08:18 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 448 Status: RO X-Status: $$$$ X-UID: 0000000012 Bill Sommerfeld writes: : > for sites that have concern about privacy, the usual value for : > RSH is /usr/local/bin/ssh. : : nit: on OS's (including solaris since s9) which have ssh integrated, : you probably mean /usr/bin/ssh. At this point, that's probably true. When I originally wrote it, that wasn't generally the case (in particular, not in solaris). I've been trying to get this through all the hoops for a long time.... Dworkin From sacadmin Thu Jun 10 15:13:49 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 16:10:55 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 689 Status: RO X-Status: $$$$ X-UID: 0000000013 Andrew Gabriel writes: : Allen Wittenauer wrote: : : > How does star handle tar files embedded with long filenames? i.e., : >will users still have to rely on GNU tar for this functionality? : : If you are referring to the ~100 character boundary, star copes : with that. There have been lots of tar versions around which : create broken archives around this 100 character boundary (GNU Star is pretty much a superset of the bulk of the tars that are out there, except in the very few cases where there are fundamental incompatibilities. It's my understanding that for the known cases, there's an option to turn on the appropriate broken behaviour. Dworkin From sacadmin Thu Jun 10 15:20:17 2004 Date: Thu, 10 Jun 2004 15:19:46 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com, Dworkin.Muller@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zodooGOJBAud2PmjGYl1Qw== Content-Length: 534 Status: RO X-Status: $$$$ X-UID: 0000000014 Not to appear ignorant, but what happens if it type /usr/sbin/rmt at the command line? From the reading of the SunOS manpage, nothing useful. Its not a true deamon, but it seems more deamon like than anything else. If this is right (or close to right), perhaps this could be external and still live in /usr/sbin or /etc. It seems that accidental discovery is not an issue. However, that's only one issue. Since this is supporting stable programs (tar) as well as external (star) it probably needs to be stable anyway. - jek3 From sacadmin Thu Jun 10 15:32:00 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 18:30:28 -0400 From: James Carlson To: "Joseph E. Kowalski III" Cc: psarc@sac.eng.sun.com, Dworkin.Muller@Sun.COM Subject: Re: PSARC/2004/480: star Content-Length: 1718 Status: RO X-Status: $$$$ X-UID: 0000000015 Joseph E. Kowalski III writes: > Not to appear ignorant, but what happens if it type /usr/sbin/rmt at > the command line? From the reading of the SunOS manpage, nothing > useful. Its not a true deamon, but it seems more deamon like than > anything else. It is the daemon end of a connection. It's no more useful than invoking /usr/sbin/in.rlogind or /usr/sbin/in.telnetd from the command line. (Those, incidentally, have even less reason to live in /usr/sbin. Unlike /etc/rmt, nothing external to the box can expect find them in those particular locations. They're kept there for the sake of old inetd.conf files and the many inetd-replacements.) > If this is right (or close to right), perhaps this could be external > and still live in /usr/sbin or /etc. It seems that accidental discovery > is not an issue. Right. The real issue is that the strings "/usr/sbin/rmt" and "/etc/rmt" form an (icky) on-the-wire protocol that selects the "rmt" protocol via (typically) in.rshd and its use of execle and pw_shell. In other words, one could have (say) a Windoze box that reads "/usr/sbin/rmt" and (lacking any such binary) says, "oh, that's the remote tape protocol; start doing that." The protocol _is_ the path. > However, that's only one issue. Since this is supporting stable programs > (tar) as well as external (star) it probably needs to be stable anyway. The path itself and the behavior of the executable (the elements of the on-the-wire protocol) must at least be Stable. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Jun 10 15:37:44 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 16:34:50 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 912 Status: RO X-Status: $$$$ X-UID: 0000000016 Joseph E. Kowalski III writes: : Not to appear ignorant, but what happens if it type /usr/sbin/rmt at : the command line? From the reading of the SunOS manpage, nothing : useful. Its not a true deamon, but it seems more deamon like than : anything else. Pretty much. You can, if you're sufficiently masochistic, use it instead of mt(1M) to manipulate the local tape drive, but the only time I've ever seen that done was when rmt itself was being worked on. It's pretty much the programmatic equivalent of mt, with just enough network awareness to handle buffering and byte-order issues. : However, that's only one issue. Since this is supporting stable programs : (tar) as well as external (star) it probably needs to be stable anyway. Tar's not a good current example (it's not remote-tape-aware), but ufsdump and ufsrestore are. For the rmt part, that seems like the right conclusion. Dworkin From sacadmin Thu Jun 10 15:37:48 2004 Date: Thu, 10 Jun 2004 15:37:16 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/480: star To: Joseph.Kowalski@eng.sun.com, james.d.carlson@Sun.COM Cc: psarc@sac.eng.sun.com, Dworkin.Muller@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2BIXyCPiwJKHHn2QljjRFQ== Content-Length: 356 Status: RO X-Status: $$$$ X-UID: 0000000017 > From: James Carlson ... > > However, that's only one issue. Since this is supporting stable programs > > (tar) as well as external (star) it probably needs to be stable anyway. > > The path itself and the behavior of the executable (the elements of > the on-the-wire protocol) must at least be Stable. Yea, what he said... From sacadmin Thu Jun 10 16:09:59 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 19:09:16 -0400 From: James Carlson To: Andy Rudoff Cc: psarc@sac.eng.sun.com, Dworkin Muller Subject: Re: PSARC/2004/480: star Content-Length: 1820 Status: RO X-Status: $$$$ X-UID: 0000000018 Andy Rudoff writes: > Finally, there is star itself, fully named ``Schilly tar'' or > more recently ``standard tar''. The latter refers to star's > full POSIX compliance. It is a functional superset of most > versions of tar(1) that are available on various operating > systems. That, the compliance, and significantly greater > throughput than the Solaris tar are the main items of > interest. For perspective, note that most of the A possibly interesting issue (that someone unnamed brought up) is that the one standard 'star' doesn't adhere to is getopts. It uses the X11-style long options -- "-help", for instance instead of "--help" -- and has some really wacky ideas about other options (such as "-/" and "-.."). It's not clear if unambiguous uses of those non-standard option mechanisms can be detangled from all reasonable single-character option usages. > With the exception of -@, all of these would be trivial to add > (and Schillling is quite likely to do so if we start shipping > star). The command line synopsis is far more general than "star" already has some conflicting options. "star -n" means "no extraction," not "random seeks." "-P" means "partial last record" rather than "suppress trailing slash." This isn't really an ARC issue, but given what I've seen in "cdrecord," and not having looked at "star" source, I'd be mildly concerned that there are major reinvented wheels inside this code. (Cdrecord has -- or at least _had_, last time I bothered with it -- its own private printf and stdio bits.) I hope that these things are being looked into. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Jun 10 16:20:23 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 17:17:27 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 835 Status: RO X-Status: $$$$ X-UID: 0000000019 James Carlson writes: : It's not clear if unambiguous uses of those non-standard option : mechanisms can be detangled from all reasonable single-character : option usages. I'll have to go digging for a bit. : This isn't really an ARC issue, but given what I've seen in : "cdrecord," and not having looked at "star" source, I'd be mildly : concerned that there are major reinvented wheels inside this code. : (Cdrecord has -- or at least _had_, last time I bothered with it -- : its own private printf and stdio bits.) I hope that these things are : being looked into. He has those, but the library those are part of are explicitly not included in what he's giving us license to (at least partly because he doesn't have clear title). His claim is that they are functional equivalents to what's in our libraries. Dworkin From sacadmin Thu Jun 10 17:12:43 2004 Date: Thu, 10 Jun 2004 17:12:10 -0700 (PDT) From: Don Cragun Subject: Re: PSARC/2004/480: star To: Andy.Rudoff@sun.com, james.d.carlson@sun.com Cc: psarc@sac.eng.sun.com, Dworkin.Muller@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fr9NinISwRWrH8ynoNbRhw== Content-Length: 1403 Status: RO X-Status: $$$$ X-UID: 0000000020 Andy Rudoff writes: > Finally, there is star itself, fully named ``Schilly tar'' or > more recently ``standard tar''. The latter refers to star's > full POSIX compliance. It is a functional superset of most > versions of tar(1) that are available on various operating > systems. That, the compliance, and significantly greater > throughput than the Solaris tar are the main items of > interest. For perspective, note that most of the To set the record straight, there is not and never has been a POSIX standard specification for the tar utility. There is a POSIX specification for the cpio archive file format, there is a POSIX specification for the ustar archive file format, and there is a POSIX specification for the pax utility and pax archive format. There were specifications for the tar and cpio utilities in XPG2, XPG3, XPG4, and XPG4v2 but they were removed in XPG5. Please also note that the POSIX interpretations committee and the Austin Group have at times disagreed with Mr. Schilling's interpretations of the standards. I'm not saying that we shouldn't adopt star, but be very careful about any standards conformance and/or compliance claims he makes. Our tar, cpio, and pax utilities produce archives that pass the standards conformance tests. I presume that you will verify that star will pass the same tests for the ustar and pax archive formats before integration. From sacadmin Thu Jun 10 21:38:26 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 22:35:31 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Status: RO X-Status: $$$$ X-UID: 0000000021 Don Cragun writes: : There were : specifications for the tar and cpio utilities in XPG2, XPG3, XPG4, and : XPG4v2 but they were removed in XPG5. I knew I'd seen them in one of the standards (probably XPG3), but had missed the removal in XPG5. : Please also note that the POSIX interpretations committee and the : Austin Group have at times disagreed with Mr. Schilling's : interpretations of the standards. This is very useful to know, particularly in light of the changes in XPG5. : Our tar, cpio, and pax utilities produce archives that pass the : standards conformance tests. I presume that you will verify that star : will pass the same tests for the ustar and pax archive formats before : integration. I certainly intend to. If there are any that aren't part of ON-PIT or the Ireland DIY/PIT tests, please send me a pointer to them, just to make sure I don't miss them. Thanks much for the additional background. Dworkin From sacadmin Thu Jun 10 21:55:42 2004 X-Authentication-Warning: weaselfish.Central.Sun.COM: dworkin set sender to Dworkin.Muller@Sun.COM using -f From: Dworkin Muller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jun 2004 22:52:48 -0600 To: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 332 Status: RO X-Status: $$$$ X-UID: 0000000022 It's been pointed out that the man pages were omitted from the case materials. That's now been rectified - the top-level man pages (rmt, star, librmt, and Schilling's comparison of star to GNU tar) are in the 2004/480/materials directory. If anyone wants the function- specific man pages for librmt, please let me know. Dworkin From sacadmin Fri Jun 11 05:01:47 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 11 Jun 2004 08:01:13 -0400 From: James Carlson To: Dworkin Muller Cc: psarc@sac.eng.sun.com Subject: Re: PSARC/2004/480: star Content-Length: 756 Status: RO X-Status: $$$$ X-UID: 0000000023 Dworkin Muller writes: > He has those, but the library those are part of are explicitly not > included in what he's giving us license to (at least partly because he > doesn't have clear title). His claim is that they are functional > equivalents to what's in our libraries. Again, not an ARC issue, but do carefully evaluate that claim. The Schilling vfprintf that I remember had a funky '%r' recursion mechanism that he used extensively, plus some really questionable (and broken on at least one platform) floating point logic. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 16 10:12:24 2004 Date: Wed, 16 Jun 2004 11:11:44 -0600 From: Andy Rudoff Subject: Re: PSARC/2004/480: star To: psarc@sac.eng.sun.com Cc: Dworkin Muller MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.6 (Macintosh/20040502) Content-Length: 63 Status: RO X-Status: $$$$ X-UID: 0000000024 This fast-track was approved at today's PSARC meeting. -andy From sacadmin Tue Sep 26 06:41:16 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8QDfGp0017289 for ; Tue, 26 Sep 2006 06:41:16 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8QDdhIw011911; Tue, 26 Sep 2006 09:39:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k8QDdf0a011908; Tue, 26 Sep 2006 09:39:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17689.11676.880325.327398@gargle.gargle.HOWL> Date: Tue, 26 Sep 2006 09:39:40 -0400 From: James Carlson To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Cc: Casper.Dik@sun.com, PSARC-EXT@sac.sfbay.sun.com Subject: star and tar (2004/480) In-Reply-To: <4519289e.RpTGE3GmrlCQxb4f%Joerg.Schilling@fokus.fraunhofer.de> References: <200609261030.k8QAUkqK394594@jurassic.eng.sun.com> <451903b3.1YNaSpouVfrM96Gf%Joerg.Schilling@fokus.fraunhofer.de> <17689.7553.632340.553985@gargle.gargle.HOWL> <200609261240.k8QCeMRM022225@vaticaan.holland.sun.com> <17689.9228.277968.222250@gargle.gargle.HOWL> <4519289e.RpTGE3GmrlCQxb4f%Joerg.Schilling@fokus.fraunhofer.de> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1374 Joerg Schilling writes: > NO, I am not talking about a _future_ project but about a project that has > already been accepted in the past. Do you mean "star" (PSARC 2004/480)? If so, that case placed no constraints or other special burdens on those proposing to modify tar(1), as far as I can tell. The only thing it said that's remotely related is this: - either usr/src/cmd/tar modified to link with librmt, or star augmented to be a full replacement for the existing Solaris tar. If the latter is done, usr/src/cmd/tar would be removed from ON and the binary replaced with a symlink to the star executable. At that time, star and ustar may also move from /usr/sfw/sbin to /usr/sbin. That's hardly a demand to stop adding new features to tar(1), and the part where there's some sort of burden on tar(1) seems to me to be the point where that "if the latter is done" sentence becomes declarative rather than subjunctive. In any event, we're straying even further from the ksh discussion. I've changed the subject line so that this side-track doesn't get archived with the ksh93 case. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Sep 26 06:55:25 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8QDtPPB017967 for ; Tue, 26 Sep 2006 06:55:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.Sun.COM [192.18.42.14]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k8QDtPg5019204 for ; Tue, 26 Sep 2006 06:55:25 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8QDbPHU011496 for ; Tue, 26 Sep 2006 06:55:22 -0700 (PDT) Received: from mms0aes.sun.com ([150.143.104.194] [150.143.104.194]) by relay1.sun.com with ESMTP; Tue, 26 Sep 2006 13:55:21 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms0aes.sun.com with ESMTP; Tue, 26 Sep 2006 13:55:21 Z Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14] [193.174.154.14]) by relay4.sun.com with ESMTP; Tue, 26 Sep 2006 13:55:20 Z Received: from burner.fokus.fraunhofer.de (burner [10.147.65.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k8QDrsd16249; Tue, 26 Sep 2006 15:53:54 +0200 (MEST) Received: (from jes@localhost) by burner.fokus.fraunhofer.de (8.12.9+Sun/8.12.9/Submit) id k8QDqSbL022205; Tue, 26 Sep 2006 15:52:28 +0200 (CEST) Date: Tue, 26 Sep 2006 15:52:28 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: james.d.carlson@sun.com Cc: PSARC-EXT@sac.sfbay.sun.com, Casper.Dik@sun.com Subject: Re: star and tar (2004/480) Message-Id: <4519309c.SN4jtTNDYHKeIBTb%Joerg.Schilling@fokus.fraunhofer.de> References: <200609261030.k8QAUkqK394594@jurassic.eng.sun.com> <451903b3.1YNaSpouVfrM96Gf%Joerg.Schilling@fokus.fraunhofer.de> <17689.7553.632340.553985@gargle.gargle.HOWL> <200609261240.k8QCeMRM022225@vaticaan.holland.sun.com> <17689.9228.277968.222250@gargle.gargle.HOWL> <4519289e.RpTGE3GmrlCQxb4f%Joerg.Schilling@fokus.fraunhofer.de> <17689.11676.880325.327398@gargle.gargle.HOWL> In-Reply-To: <17689.11676.880325.327398@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO8859-1 Content-Transfer-Encoding: 8bit Sender: schilling@fokus.fraunhofer.de Status: RO Content-Length: 1128 James Carlson wrote: > Joerg Schilling writes: > > NO, I am not talking about a _future_ project but about a project that has > > already been accepted in the past. > > Do you mean "star" (PSARC 2004/480)? If so, that case placed no > constraints or other special burdens on those proposing to modify > tar(1), as far as I can tell. The only thing it said that's remotely > related is this: ... > That's hardly a demand to stop adding new features to tar(1), and the > part where there's some sort of burden on tar(1) seems to me to be the > point where that "if the latter is done" sentence becomes declarative > rather than subjunctive. Well, it is a matter of cooperative will not to add things without asking before. in such a case. This is the reason why I belive this needs to be discucced. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Fri May 11 02:57:07 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4B9v6Su022872 for ; Fri, 11 May 2007 02:57:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4B9toin024653 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 11 May 2007 10:56:01 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHV00B0PFLBG400@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 11 May 2007 02:55:59 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHV0033WFL9FUA0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 11 May 2007 02:55:58 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4B9tvuj009921 for ; Fri, 11 May 2007 09:55:57 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHV00E01FCFIP00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 11 May 2007 10:55:57 +0100 (BST) Received: from [129.156.173.136] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHV00L4PFL7CP30@d1-emea-09.sun.com>; Fri, 11 May 2007 10:55:55 +0100 (BST) Date: Fri, 11 May 2007 10:55:55 +0100 From: Darren J Moffat Subject: PSARC/2004/480 star (Was Re: PSARC 2007 267 vim (Vi IMproved) 7) In-reply-to: <4644398a.cpe8WVMo/KtgM25r%Joerg.Schilling@fokus.fraunhofer.de> Sender: Darren.Moffat@sun.com To: Joerg Schilling Cc: james.mcpherson@sun.com, psarc-ext@sun.com, Danek.Duvall@sun.com Message-id: <46443DAB.7010808@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070510225914.GZ9806@zruty.sfbay.sun.com> <46441863.rtmTkEiW2QqA5pbx%Joerg.Schilling@fokus.fraunhofer.de> <46441A26.7090905@Sun.COM> <4644398a.cpe8WVMo/KtgM25r%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0b2 (X11/20070411) Status: RO Content-Length: 706 Joerg Schilling wrote: > "James C. McPherson" wrote: > > >>> What we need is real actions not only plans. >>> >>> Please help to put PSARC 2004/480 into reality and before filing new ideas. >> >> Hi Joerg, >> what are you, as the author of star, doing to advance >> that PSARC case? > > In principle, I am waiting for the integration to happen since 2004. > Note that this was expected to happen before Solaris 10 GA was published. This is NOT relevant to the technical review of this case please take it off this thread. If you want to discuss PSARC/2004/480 please put PSARC/2004/480 in the subject line, the ARC tools archive email appropriately. -- Darren J Moffat From sacadmin Fri May 11 03:00:50 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4BA0nCH022988 for ; Fri, 11 May 2007 03:00:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4B9xYTq026057 for <@sunmail3mpk.sfbay.sun.com:psarc@sun.com>; Fri, 11 May 2007 10:59:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JHV00507FRJMC00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 11 May 2007 02:59:43 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JHV00DERFRHZ5A0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 11 May 2007 02:59:42 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4B9xfO9002063 for ; Fri, 11 May 2007 09:59:41 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHV00301FPAPG00@mail-apac.sun.com> (original mail from James.McPherson@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Fri, 11 May 2007 17:59:41 +0800 (SGT) Received: from [129.150.153.2] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHV007V7FRC6YZC@mail-apac.sun.com>; Fri, 11 May 2007 17:59:40 +0800 (SGT) Date: Fri, 11 May 2007 19:59:34 +1000 From: "James C. McPherson" Subject: Re: PSARC/2004/480 star (Was Re: PSARC 2007 267 vim (Vi IMproved) 7) In-reply-to: <46443DAB.7010808@Sun.COM> Sender: James.McPherson@sun.com To: Darren J Moffat Cc: psarc@sun.com, Danek.Duvall@sun.com Reply-to: James.McPherson@sun.com Message-id: <46443E86.3000900@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070510225914.GZ9806@zruty.sfbay.sun.com> <46441863.rtmTkEiW2QqA5pbx%Joerg.Schilling@fokus.fraunhofer.de> <46441A26.7090905@Sun.COM> <4644398a.cpe8WVMo/KtgM25r%Joerg.Schilling@fokus.fraunhofer.de> <46443DAB.7010808@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070123) Status: RO Content-Length: 967 Darren J Moffat wrote: > Joerg Schilling wrote: >> "James C. McPherson" wrote: >> >> >>>> What we need is real actions not only plans. >>>> >>>> Please help to put PSARC 2004/480 into reality and before filing new >>>> ideas. >>> >>> Hi Joerg, >>> what are you, as the author of star, doing to advance >>> that PSARC case? >> >> In principle, I am waiting for the integration to happen since 2004. >> Note that this was expected to happen before Solaris 10 GA was published. > > This is NOT relevant to the technical review of this case please take it > off this thread. > > If you want to discuss PSARC/2004/480 please put PSARC/2004/480 in the > subject line, the ARC tools archive email appropriately. Hi Darren and PSARC, please accept my apologies for not paying attention to the lists and people that were included on my response to Joerg. best regards, James C. McPherson -- Solaris kernel software engineer Sun Microsystems