open source sed [PSARC/2010/086 FastTrack timeout 03/17/2010]
On 11/03/10 10:28 AM, Garrett D'Amore - sun microsystems wrote: Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: open source sed 1.2. Name of Document Author/Supplier: Author: Olga Kryzhanovska 1.3 Date of This Document: 10 March, 2010 4. Technical Description I'm sponsoring this fast-track request on behalf of the POSIX utility community and shell project. Please note that this is an *open* case. The release binding is the same as with the ksh93 project: a patch/micro release of Solaris delivering through ON Stability levels are as described below. This project is an amendment to the Korn Shell 93 Integration project (PSARC/2006/550 and PSARC/2007/035, PSARC/2008/094, PSARC/2008/344 and PSARC/2008/589) specifying the following additional interfaces: Provide an opensource version of /usr/bin/sed and /usr/xpg4/bin/sed +1e1 from me. James C. McPherson -- Senior Software Engineer, Solaris Oracle http://www.jmcp.homeunix.com/blog
Question concerning ARC agendas and minutes
Rainer Orth wrote: Asa Romberger Asa.Romberger at Sun.COM writes: My proposal is to eliminate the email entirely and post both the ARC agendas and the ARC minutes at http://www.opensolaris.org/os/community/arc/announcements. If you have a major objection to this, please let me know. Otherwise I will start this practice next week. I'm strongly opposed to this: replacing notifications by a mechanism where you need to poll the information is backwards ;-( While there is an RSS feed for this page @ http://www.opensolaris.org/rss/os/community/arc/announcements/rss2.xml I still prefer to get the announcements via email. I'm sure I am not the only person who spends more time with an email client than an RSS reader. James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
On Tue, 08 Sep 2009 10:55:57 -0700 Garrett D'Amore gdamore at sun.com wrote: James Carlson wrote: Given that, I'd actually prefer to remove the queue.h interfaces, and promote list.h. list.h interfaces are safer than BSD queue.h (see above argument), and have been around and available since ~forever. Please don't! The BSD queue.h interfaces are used in both kernel *and* user-space code -- they're also present on Linux -- and the lack of them on classic Solaris is a very annoying application portability issue. Removing them would be a big step backwards. Ok. Well in this case, someone else should raise the commitment level and ARC them. Just having them appear on Solaris without any ARC coverage or interface stability is IMO less than helpful. It looks like this arrived with the Packet Filter Hooks stuff. Correct: 6418698 PSARC/2005/334 - Packet Filtering Hooks API (not introduced by fwflash at all, I just used what was already there) James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
fakeroot [PSARC/2009/406 FastTrack timeout 07/28/2009]
On Tue, 21 Jul 2009 19:12:30 -0500 Nicolas Williams Nicolas.Williams at Sun.COM wrote: On Tue, Jul 21, 2009 at 04:53:48PM -0700, Garrett D'Amore wrote: I don't understand the point of this. Why is this kind of emulation helpful? Is this just to create honeypot? Or am I missing something. No. Remember when ON had to be built as UID 0? It's for that sort of purpose. ... something that I'm working hard to fully remove. Requiring a build as uid 0 has long since past its use-by date. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
EOF UCB Device Names [PSARC/2009/346 timeout 06/16/2009]
On Tue, 09 Jun 2009 20:49:31 -0700 (PDT) Richard L. Hamilton rlhamil at smart.net wrote: ... I see dev_path and dev_link properties associated with storage devices in prtconf -v output. If those are actual driver properties, they are available to the kernel, right? So mapping from one to another (minus slice, if applicable) in a message ought to be possible, unless I'm missing something. No, they're not driver properties per se, they're an artefact of libdevinfo - have a read of di_devlink_init, di_devlink_path and di_devlink_walk (all 3DEVINFO). For a fairly simple example of how they're used, wander through http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/stmsboot/stmsboot_util.c#1085 cheers, James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
PSARC 2008/443 Driver for LSI MPT2.0 compliant SAS 2.0 controller
On Sat, 09 May 2009 14:31:05 +0100 Ceri Davies ceri at submonkey.net wrote: On Tue, Apr 21, 2009 at 01:19:54AM +, Javen Wu wrote: Hi Garrett, Actually the proposed project includes the modification of stmsboot(1M) to support mpt_sas(7D), which is a utility to enable/disable mpxio for PHCI drivers . I assume all PHCI drivers should do the modification, I should have added a statement for stmsboot support in section 4.5. As for the utility to control individual instances of the driver is a good suggestion, we'll take it as a new project. :) As someone who just migrated data from one SAN where mpxio was not in use to a different SAN where it was, some way of doing it without rebooting would be nice too. That *should* be orthogonal to the problem of data migration, let alone to this case. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
pywbem Ver 0.7 [LSARC/2009/258 FastTrack timeout 05/05/2009]
On Tue, 28 Apr 2009 07:30:06 -0700 (PDT) Mark Carlson markcarl at sac.sfbay.sun.com wrote: I am sponsoring this familiarity case for Vivek Titarmare. It requests minor binding and times out 05/05/2009. -- mark 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: pywbem Ver 0.7 1.2. Name of Document Author/Supplier: Author: Vivek Titarmare 1.3 Date of This Document: 28 April, 2009 2. Project Summary 2.1 Project Description Python WBEM Client and Provider Interface 4. Technical Description: PyWBEM is a Python library for making CIM operations over HTTP using the WBEM CIM-XML protocol. It is based on the idea that a good WBEM client should be easy to use and not necessarily require a large amount of programming knowlege. PyWBEM is suitable for a large range of tasks from simply poking around to writing web and GUI applications. Does this have any dependency upon the existing ON WBEM code? If it does, *why* ? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
PSARC 2008/443 Driver for LSI MPT2.0 compliant SAS 2.0 controller
On Wed, 22 Apr 2009 15:36:32 -0400 Torrey McMahon Torrey.McMahon at Sun.COM wrote: It's really more of a nitpick. I just see some weird conversations like Customer: I'm using this LSI SAS controller so I use mpt_sas, right? Sun Tech: No you use mpt. Customer: Huh? What's the difference Sun Tech: mpt_sas is for new SAS controllers. mpt is for some of the older SAS controllers. Customer: They both work on SAS controllers? How do I know which is which? Sun Tech: Man page[?] Wouldn't something like mpt2 make more sense? Again, total nitpick. I'm not going to argue or anything over a name. It just seems kind of weird. :) mpt2 is a driver + instance number, which would interfere with existing installations. What we're trying to do with this mpt_sas name (and the mr_sas name for the MegaRAID SAS 2nd gen HBAs) is make it clear that this is a driver for a closely related family of hardware. The chips which the customer will most likely get to know that use this new driver are all LSI SAS2..., whereas for mpt(7d) they are LSI SAS1 and the parallel SCSI forms. So your conversation snippet above should say Sun Tech: mpt_sas is for 2nd generation LSI SAS controllers. mpt is for the 1st generation LSI SAS controllers. And yes, the manpages will make this very clear. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
PSARC 2008/443 Driver for LSI MPT2.0 compliant SAS 2.0 controller
On Mon, 20 Apr 2009 22:09:58 -0400 Torrey McMahon Torrey.McMahon at Sun.COM wrote: Is mpt_sas going to replace mpt? Or could both drivers be loaded at the same time? Both drivers can be loaded at the same time. mpt(7d) supports Parallel SCSI and SAS generation 1 only. mpt_sas(7d) does not support Parallel SCSI or SAS generation 1. If mpt_sas is going to support SAS and SATA drives isn't the name a a little confusing? Perhaps. Since the driver is actually to support the HBA rather than SAS or SATA drives I don't think that matters. James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel
Specification update for Pluggable fwflash [PSARC/2009/163 FastTrack timeout 03/16/2009]
Hi James, On Mon, 09 Mar 2009 09:37:58 -0400 James Carlson James.D.Carlson at Sun.COM wrote: Alan Hargreaves writes: and if an identification plugin defines unsigned int plugin_version = FWPLUGIN_VERSION_2; in its struct fw_plugin definition, then the fwflash cleanup function I don't think I understand that. First of all (as a nit), 2008/151 didn't include versioning, so it'd be good to describe how it works here. I didn't worry about versioning with 2008/151 - and I should have thought further when designing it. Benefit of hindsight :| The idea is that when a new structure element (for any of the existing structures) or a new structure is defined, we would bump the version number, so $SRC/cmd/fwflash/common/fwflash.c would be able to deal with the change in an appropriate fashion. Existing plugins would not need to be redelivered because their behaviour would not change. Reading the existing header file, it seems that plugins must define a uint32_t variable (not a struct) that has the name fwplugin_version, and that's what's used for the versioning, not plugin_version as above. Is that correct, or are there other changes here? Does the integer change to a structure? Is there a new variable? Reviewing the existing header file, I see that there are extraneous comments about versioning left over from a very early version of the original spec. The existing comments are wrong, not only are plugins not required to define any version-related element in any structure, but even if they did (now), we have no way of using that information. We are proposing to add the integer plugin_version (or fwplugin_version, I'm not wedded to the exact name). There is no new structure. I would have expected just a new #define. int (*fw_cleanup)(struct devicelist *thisdev); It is an error condition for an identification plugin to define plugin_version = FWPLUGIN_VERSION_2, and to not also define the fw_cleanup() function. One tiny nit here: I think you'd probably be better off making it so that plugins simply use FWPLUGIN_VERSION_CURRENT, and the framework calls fw_cleanup if the version is =2 and the function pointer is non-NULL. That way, old plugins will correctly inform the framework that they've been compiled with an old version of this structure (and thus the new fw_cleanup member is located one word off the end) by saying version 1, and new plugins that don't need to clean anything up won't be forced into providing a dummy function. For the teardown part, that's pretty much how I've got it implemented (except for the #define name) in my prototype. (The real issue here is that structures like this should be allocated by the framework so that you don't have to bump a version number when new members are allocated. The versioning needs to be tied with the allocation of space for that structure. But I guess it's too late to fix that ...) Yes, I agree. Again, benefit of hindsight. For that matter, if I was designing Pluggable fwflash all over again I'd skip use of the sys/queue.h header and just use libnvpair instead. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Video Decode and Presentation API for Unix (VDPAU) [PSARC/2009/059 FastTrack timeout 02/05/2009]
On Thu, 29 Jan 2009 10:54:27 -0800 (PST) John Fischer johnf at sr1-umpk-12.sfbay.sun.com wrote: Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Video Decode and Presentation API for Unix (VDPAU) 1.2. Name of Document Author/Supplier: Author: John Martin 1.3 Date of This Document: 29 January, 2009 4. Technical Description Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Video Decode and Presentation API for Unix (VDPAU) 1.2. Name of Document Author/Supplier: Author: John Martin 1.3 Date of This Document: 29 January, 2009 4. Technical Description The Video Decode and Presentation API for Unix (VDPAU) is a development and runtime environment which provides decode, post-processing, compositing, and display of compressed and uncompressed video streams. It is not a standalone video player but instead an environment which can be used by video players and other video applications. It also does not address content protection. How does this relate to the Video4Linux v2 (V4L2) API? What presentation applications have been created to demonstrate how VDPAU works? thankyou, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
GNU Developer Collection [LSARC/2008/776 FastTrack timeout 01/07/2009]
On Wed, 17 Dec 2008 16:15:05 -0800 Raj Prakash Raj.Prakash at Sun.COM wrote: Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know 1. Introduction 1.1. Project/Component Working Name: GNU Developer Collection ... 2. Project Summary 2.1. Project Description: The project will provide the current releases of the GNU Compiler Collection (GCC) and the GNU Binutils for OpenSolaris. The primary components are the following: - GCC includes C, C++, FORTRAN, Objective-C, and Objective-C++. - GNU Binutils includes a collection of binary tools, the most notable being the assembler and linker. - GCC Runtime includes the runtime libraries corresponding to the compiler collection. You seem to be conflicting with 6674032 Introduce GCC 4.3.x in Nevada 6674042 Introduce MPFR (Multiple Precision Floating-Point Rounding Library) in Nevada 6674044 Introduce GNU MP 4.2.4 in Nevada James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
sg3 utilities 1.25 [PSARC/2008/683]
On Thu, 13 Nov 2008 20:33:36 -0800 Matthew Jacob Matthew.Jacob at Sun.COM wrote: Garrett D'Amore wrote: ... These days we have libscsi and friends. Application developers should be able to use those directly. You're kidding, right? ultra20 man libscsi No manual entry for libscsi. Looking at the case materials for 2008/196 (which, btw, is a painful process when going through opensolaris.org), libscsi, and libses, are built on top of sgen(7d). Jesus wept, this misses the points I've been trying to make. No, he's not kidding. This is pretty much the same question I asked last week. Just because there's no manpage doesn't mean that it's impossible to use - or don't people read source code any more? libses makes use of sgen(7d), but libscsi doesn't mandate use of libses. Pluggable fwflash(1m) uses both libscsi and libses, and the code for almost of it is open. What's your underlying objection to using libscsi and/or libses? James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Areca Backup [LSARC/2008/681 Self Review]
Grant Zhang wrote: I agree with Mark. The point of porting many FOSS packages into Open Solaris is to make people comfortable enough in using the very same tools in Open Solaris. Back to this case, Areca is a backup utility, not a crypto utility. Encryption is just one feature provided by Areca, although as you observed, not very strong encryption. It is possible to use Areca to back up the files totally unencrypted, which is not uncommon in personal backup space. For folks with strong security needs, encrypt(1) or mac(1) can still be used on the backups. Areca is an active project and a lot of people are using it on Windows and Linux. Please don't reject it so we have one less choice on OpenSolaris. Please don't try to ignore the valid architectural and security concerns which Darren and others have raised already. If this Areca backup util is to be integrated, then its crypto support should Do The Right Thing in OpenSolaris rather than merely assume that whatever is being done elsewhere is preferable. Oh, and has anybody informed the Areca project group that their name conflicts with that of a company (Areca Technologies Ltd of Taiwan) ? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Sg3 utilities 1.25 [LSARC/2008/683 Self Review]
Uncommitted Manpage /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage /usr/share/man/man8/sg_start.8Uncommitted Manpage /usr/share/man/man8/sg_verify.8 Uncommitted Manpage /usr/share/man/man8/sg_modes.8Uncommitted Manpage /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage /usr/share/man/man8/sg_ident.8Uncommitted Manpage /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage /usr/share/man/man8/sg_inq.8 Uncommitted Manpage /usr/share/man/man8/sg_raw.8 Uncommitted Manpage /usr/share/man/man8/sg_turs.8 Uncommitted Manpage /usr/share/man/man8/sg_sync.8 Uncommitted Manpage /usr/share/man/man8/sg_logs.8 Uncommitted Manpage /usr/share/man/man8/sg_format.8 Uncommitted Manpage /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage The following additional installed files are not interface. Additional document --- N/A 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open ___ opensolaris-arc mailing list opensolaris-arc at opensolaris.org -- James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
PSARC 2008/504 Device Driver Utility
Jack wrote: Will this utility work during installation? The short answer is yes - particularly if you're running this from the OpenSolaris 2008.05 (or later) liveCD. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
PSARC 2008/504 Device Driver Utility
James Carlson wrote: James C. McPherson writes: Frank Che wrote: I'm sponsoring this fast track for Bill Yan. Requested release binding is patch/micro for OpenSolaris. Timer is set to 08/13/2008. Note that this project depends on the IPS project (PSARC 2008/190) which is still under development now. So you want this to go into a Solaris 10 Update? Why? I would have expected minor for the release binding since you have a dependency on the IPS project. No -- he specifically mentions OpenSolaris as the delivery vehicle, not Solaris. It's not for an S10 Update. It just has no architectural impact of its own that requires a Minor release binding. Anywhere IPS could go, it would go. True, and I consider the patch/micro request to be incorrect in this context also. James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
PSARC/2008/018 Integrate OpenUSB into Solaris
Roger Fujii wrote: Not sure if this is the right place for this, but as libopenusb is in snv, shouldn't the source for it be available in the mercurial repository? Hi Roger, It's part of the SFW consolidation, rather than ON: http://src.opensolaris.org/source/xref/sfw/usr/src/lib/openusb/ There's a project page (http://opensolaris.org/os/project/companion) which points to svn+ssh://anon at svn dot opensolaris dot org/svn/companion/core/usr and the other project page http://opensolaris.org/os/project/sfwnv has an Install / Quickstart link http://opensolaris.org/os/project/sfwnv/Documents/install_quickstart which says you should download a tarball of the source first. hth, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
LSARC/2008/477 - XChat IRC client
John Fischer wrote: All, I am sponsoring this project for Laszlo (Laca) Peter from the JDS Desktop group in Dublin Ireland. The case directory contains this proposal. I have set the timer for next Friday August 1, 2008. The project requests a Patch release binding to integrate the Open Source XChat IRC client. This project falls into the Linux familiarity directive. 4 Imported Interfaces Interface ClassificationComments - -- ... DBUS (libdbus-1.so.3) Volatile Running any DBUS client application in a zone will cause it and any other DBUS client application to hang. Will this delivery of XChat come with a caveat that it's not usable in a zone, or will there be a workaround built in? Alternatively, what is the plan to make DBUS zone-friendly? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
RaidCfg GUID and volume activation support [PSARC/2008/458 FastTrack timeout 07/24/2008]
Hi Jerend, will this fasttrack address the issues in 6523832 raidctl cannot support mpxio-capable disks when mpxio enabled on the hba controller. and 6544176 raidctl manpage needs updating thankyou, James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Songbird for OpenSolaris [LSARC/2008/459 FastTrack timeout 07/24/2008]
Shi-Ying Irene Huang wrote: ... 4. Technical Description: 4.1. Details: Songbird is a complete desktop media player or jukebox with a uniquely open approach to Internet digital media network services. It runs on Mozilla's XULRunner platform and utilizes GStreamer media framework for media playback. ... Imported Interface Interface Classification ARC case Comment GNOME Platform CommittedLSARC/2008/207 GTK+ library Libraries GNOME 2.22 SQLite Uncommitted PSARC/2008/120 SQLite library NSS/NSPR CommittedWSARC/2007/548 NSS/NSPR libraries FreeType Volatile LSARC/2007/662 freetype library The versions of NSS/NSPR in Nevada are lower than required. We will deliver private ones for now, and remove the private ones after those libraries get upgraded in Nevada. Hi Irene, I'm very pleased to see that Songbird is now on the radar for inclusion. I have some questions for you: Which version of Songbird will the project team integrate initially (and how often will it be updated?). There are always comments on Songbird fora about obtaining new media plugins. What will the project team do to make this process easy to follow? Will there be, for instance, an IPS package of plugins and config which a user can download and install in a painless fashion? I'm less than impressed that we have yet another case that plans to deliver its own copy of nss/nspr. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
avant-window-navigator for OpenSolaris [LSARC/2008/452 FastTrack timeout 07/22/2008]
Henry Zhang wrote: Danek Duvall ??: On Wed, Jul 16, 2008 at 08:27:42PM +0800, Henry Zhang wrote: How will this interact with the existing GNOME Panel? Yes, this is a good question, AWN is an opinion for user to use, it will appear only when you start it, while GNOME Panel will exist always. These 2 tools can exist at the same time, 1, we can use arrow in the Gnome Panel to make Gnome Panel minimize, 2, Generally we can make the Gnome Panel in the top of the screen, and AWN at the bottom of the screen. In fact there is no impact between them, you can use any of them to control your system. Can AWN completely replace the gnome panel? No, I don't think so, at least no plan at the moment. Can it swallow gnome panel applets and throw up the gnome menus? AWN is at the bottom of the screen, so they may appear together if you set the gnome panel at the bottom too. AWN can't throw up the menu at the moment. Or does it live in a completely separate space? It keep at the bottom of the screen. You keep referring to this assumption that everybody who uses GNOME has their Panel at the top of the screen. Why do you make this assumption? One of the advantages of GNOME is, in fact, its user configurability so that we're not all forced to use the same screen layout. Can AWN be positioned on any user-selectable area of the screen, or is it restricted to just being at the bottom? It would be less than useful if AWN imposed such a restriction. Screen real estate is at a premium, especially on laptops. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
avant-window-navigator for OpenSolaris [LSARC/2008/452 FastTrack timeout 07/22/2008]
Shi-Ying Irene Huang wrote: ... 3.3. Business Justification: Avant Window Navigator (Awn) is a dock-like bar which sits at the bottom of the screen. It has support for launchers, task lists, and third party applets. So it can provide user an easy way to track the opened windows, and user can launch some location by simply click some launcher, user also can add applets, and set the theme to make AWN looks very cool. 3.4. Competitive Analysis: Mac OS has leopard Dock. Hi Irene, I'm sorry, I really do not think you've argued the business justification at all: looks very cool does not work for me. Did you perhaps mean to say that you want this integrated in order to provide a user experience which is comparable to that of Mac OS X or the latest bleeding edge linux desktop? How will this interact with the existing GNOME Panel? What requirements are there for applications to ensure that they behave properly with AWN? Will I have to recompile things in order to get the stick to desktop #Z behaviour? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
ITU construction tools [PSARC/2008/431 FastTrack timeout 07/16/2008]
James C. McPherson wrote: Jan Friedel wrote: Below described approach seems to be related only to x86/GRUB systems. Do we have some sort of support for SPARC machines (already there / planned)? Hi Jan, you're right, the utilities as they currently exist are specificly for x86/x64 systems. I had not worried about SPARC support since I've not yet come across any request from an IHV/ISV to provide this sort of facility. I am quite happy to work on it for a followup phase, especially since we've now got GRUB for SPARC. ahem... of course I meant now we've got Newboot for SPARC which has a ramdisk and boot_archive. :-) James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Clutter for OpenSolaris [LSARC/2008/426 FastTrack timeout 07/05/2008]
Shi-Ying Irene Huang wrote: Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Clutter for OpenSolaris 1.2. Name of Document Author/Supplier: Author: Chris Wang 1.3 Date of This Document: 07 July, 2008 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: Clutter for Solaris ... 2. Clutter community http://clutter-project.org/ 3. API reference http://clutter-project.org/docs/clutter/0.6/ Apart from the name (don't we want _less_ clutter? haha), what is the plan to migrate to the 0.7.x version of the API, which is currently in unstable ? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
tsclient for Opensolaris [LSARC/2008/414 FastTrack timeout 07/08/2008]
Shi-Ying Irene Huang wrote: Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: tsclient for Opensolaris It's about time, too! When will this fasttrack timeout? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Location of com.sun.trustedsolaris.*
arpit wrote: Hi to all, I am new to solaris. I am working on the problem of WBEM service in Solaris 9/07, and in that I am not able to find out com.sun.trustedsolaris jar file... Can you plz tell me, the location of com.sun.trustedsolaris.* ? Which jar should I include? Neither of these lists are appropriate to ask this question on. If you need this information about Solaris 9 then you should log a service call with Sun and follow that process. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
Dear all, One minor addition to the spec for Pluggable fwflash(1M): delivery of 64bit entities for each of the verification and identification plugins. These will go into usr/lib/fwflash/verify/$ISA and usr/lib/fwflash/identify/$ISA The CR tracking these changes is 6688492 fwflash needs 64bit plugins James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Request for sponsor - proj - FastTrack
? wrote: Roland Mainz wrote: Magne M?hre wrote: ...[snip]... 4.5. Interfaces: Provided interfaces: package: SUNWproj uncommitted include files: /usr/include/nad_list.huncommitted /usr/include/org_proj4_Projections.h uncommitted /usr/include/proj_api.huncommitted /usr/include/projects.huncommitted Is it possible to move this into a subdir like /usr/include/postgres/ or /usr/include/proj4/ ? I'm a bit worried that this stuff more or less sits in the global include namespace for all applications... for example /usr/include/project.h may be confused with /usr/include/projects.h which is a system header for the Solaris projects feature. proj is not a postgresql package. It is a generic support library for GIS applications, and widely used in that business segment. I have no objections to putting the include files in /usr/include/proj4, if that is the recommended approach ? When I designed Pluggable fwflash, I included delivery of a header file in usr/include/fwflash. I believe that this is the appropriate model to follow in general. user binaries: Same question here: Is there a reason why this must be in /usr/bin/ and cannot sit in /usr/postgres/bin/, /usr/postgres/bin/ or /usr/proj4/bin/ ? If it should remain in /usr/bin/ - would it be usefull to add proj4_ as prefix for all utilties (except proj itself) ? I'm opposed to adding a prefix as that would confuse users. A separate directory (/usr/proj4/bin) is acceptable to me Confusion because it's not what users see on other platforms? I can understand that. I don't think placing these binaries in a separate hierarchy is necessarily a good idea - I get the impression that proj isn't a large entity such as the xpg4 and gnu deliveries, so I'd stick with usr/bin in this case. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Integrate LSI MegaRAID SAS controllers (eg. 1078) driver (mega_sas) into Solaris [PSARC/2008/051 FastTrack timeout 02/01/2008]
Bill wrote: There is a recently filed PSARC case for a community driver, PSARC/2008/011 - mfi driver http://sac.sfbay/PSARC/2008/011/. The two teams have agreed that the two drivers will coexist, and the LSI driver will be the default. 2Reference: Supporting SLA/CDA and other documentation is available at: http://ego02-x86.west.sun.com/wiki/index.php/SMALL:LSI_IHV_Status The stated reference link and PSARC case link are non existant. They do exist, but not outside Sun's network. You aren't going to get to see the SLA or CDA. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Integrate LSI MegaRAID SAS controllers (eg. 1078) driver (mega_sas) into Solaris [PSARC/2008/051 FastTrack timeout 02/01/2008]
James C. McPherson wrote: Bill wrote: There is a recently filed PSARC case for a community driver, PSARC/2008/011 - mfi driver http://sac.sfbay/PSARC/2008/011/. The two teams have agreed that the two drivers will coexist, and the LSI driver will be the default. 2Reference: Supporting SLA/CDA and other documentation is available at: http://ego02-x86.west.sun.com/wiki/index.php/SMALL:LSI_IHV_Status The stated reference link and PSARC case link are non existant. They do exist, but not outside Sun's network. Slight correction, the mfi fasttrack is available at http://opensolaris.org/os/community/arc/caselog/2008/011/ You aren't going to get to see the SLA or CDA. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Bier [PSARC/2008/230 FastTrack timeout 04/01/2008]
Brian Utterback wrote: James C. McPherson wrote: No doubt we'd need to have one for duff(1), dufflite(1) and duffzero(1), and another one for fosters(1) too, with a See Also that mentions both bud(1) and coors(1). Can these be made compatible? Instead of duplicating the code needlessly, perhaps we could have a single executable, ontap(1) with a brand flag, -b that would specify the particular flavor to dispense? If necessary, we could still have the individual commands via links to the ontap command, which would cause the ontap command to behave as if it were called like this: ontap -b $0. Given my mental image of duff(1), dufflite(1) and duffzero(1) from the Homer and Barney go on the Duff Brewery Tour episode[1], I think that would be perfectly acceptable :-) [1] http://en.wikipedia.org/wiki/Duffless James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Bier [PSARC/2008/230 FastTrack timeout 04/01/2008]
Scott Rotondo wrote: Joseph Kowalski wrote: Behind in my mail,... Because let's face it, without wine(1) I think this case is woefully incomplete. And make sure to include the --red, --white, --ros?, --varietal=VARIETAL, and other important options. This being FOSS we'll just have to accept GNU-style long options and to -hiccup- hell with the CLIP. I know this is already approved, but I strongly advise removing the --rose and --varietal=WHITE_ZIN options. Solaris has a reputation of quality and maturity that should not be imputed by the inclusive attitudes of young FOSS developers. But white zinfandel has the third-largest market share by case volume [1]. Clearly the community has spoken, and they find that white zin meets their beverage needs. Who are we to impose our elitist ivory-tower quality standards? We are Correct(tm), and are the only ones who appreciate why White Zin is only slightly better than PassionPop. /me wanders off in a Coonwarra shiraz-induced red haze... Watch for future fast-tracks to implement bud(1) and coors(1). Although some might argue that they duplicate much of the functionality of beer(1), the implementation is completely different, and there is a substantial installed base that demands 100% compatibility. It should be possible to provide sufficient packaging metadata to prevent accidental consumption of bud(1) and coors(1) by the unwary. No doubt we'd need to have one for duff(1), dufflite(1) and duffzero(1), and another one for fosters(1) too, with a See Also that mentions both bud(1) and coors(1). James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Bier [PSARC/2008/230 FastTrack timeout 04/01/2008]
Nicolas Williams wrote: On Tue, Apr 01, 2008 at 12:07:34AM -0700, Randy Fishel wrote: This case describes the proper usage model for the common zymological beverage, beer(1). Though the beverage 'wine(1)' has similar processes and has similar results, the density and concentrations are different, so this case will not include 'wine(1)'. This case will also not include common compression techniques (warming and cooling), but will reference them. What is the overall architecture here? Is there an Alcoholic Beverage umbrella project, or did I miss it? Because let's face it, without wine(1) I think this case is woefully incomplete. And make sure to include the --red, --white, --ros?, --varietal=VARIETAL, and other important options. This being FOSS we'll just have to accept GNU-style long options and to -hiccup- hell with the CLIP. Don't forget the --fortified and --liqueur options. There should probably be another case as well - spirits(1) - for completeness if nothing else. Methinks that spirits(1) should have a --nationality option as well. hic! James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
Hi all, I forgot to provide an updated manpage for Pluggable fwflash that mentions the new usage and supported plugins. I've attached the plain text version, nroff version and diffs from the existing version. The CR tracking the changes is 6681880 fwflash(1m) manpage needs updating for Pluggable fwflash. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog -- next part -- An embedded and charset-unspecified text was scrubbed... Name: fwflash.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080331/f0a45192/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: fwflash.1m URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080331/f0a45192/attachment.ksh -- next part -- An embedded and charset-unspecified text was scrubbed... Name: fwflash.1m.diffs URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080331/f0a45192/attachment-0001.ksh
PSARC 2008/196 libscsi and libses
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
Joerg Schilling wrote:
Is libscsi intended to be a project private lib that is undocumented and
not available as shared library?
Summary of Exported Interfaces, all Contracted Consolidation Private:
...
SCSI libraries and private commands
/usr/lib/scsi/libscsi.so.1
/usr/lib/scsi/{amd64,sparcv9}/libscsi.so.1
Note the file location and the explicit mention twice that this is private.
Then avoid name space pollution and do not use a generic name for this lib.
Has this fasttrack timed out and got an automatic approval yet?
James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
PSARC 2008/196 libscsi and libses
Eric Schrock wrote:
On Mon, Mar 17, 2008 at 10:01:36AM +1000, James C. McPherson wrote:
Hi Eric,
Could we get some common status code mappings / handlers
added to ses2.h? Something common that makes use of the
definitions in ses2_dl_ucode_status would probably be a
good thing.
I'm not sure what you're asking for. The ses2_dl_ucode_status_t values
are available in the SES_EN_PROP_UCODE property of the enclosure node.
Why would we need any mappings / handlers, and what would they do?
Hi Eric,
I was thinking that having something like the following as
common code would be preferable to seeing consumers of libses
rolling their own each time they needed some status mappings:
typedef struct ucode_statdesc {
uint64_tus_value;
const char *us_desc;
boolean_t us_pending;
boolean_t us_iserr;
} ucode_statdesc_t;
static ucode_statdesc_t ucode_statdesc_table[] = {
{ SES2_DLUCODE_S_NOP, none, B_FALSE, B_FALSE },
{ SES2_DLUCODE_S_INPROGRESS,in progress, B_TRUE, B_FALSE },
{ SES2_DLUCODE_S_SAVING,saved, B_TRUE, B_FALSE },
{ SES2_DLUCODE_S_COMPLETE_NOW, completed (available), B_FALSE,
B_FALSE },
{ SES2_DLUCODE_S_COMPLETE_AT_RESET,
completed (need reset or power on), B_FALSE, B_FALSE },
{ SES2_DLUCODE_S_COMPLETE_AT_POWERON, completed (need power on),
B_FALSE, B_FALSE },
{ SES2_DLUCODE_S_PAGE_ERR, page error (offset %d),
B_FALSE, B_TRUE },
{ SES2_DLUCODE_S_IMAGE_ERR, invalid image,
B_FALSE, B_TRUE },
{ SES2_DLUCODE_S_TIMEOUT, download timeout,
B_FALSE, B_TRUE },
{ SES2_DLUCODE_S_INTERNAL_NEEDIMAGE,
internal error (NEED NEW IMAGE BEFORE RESET),
B_FALSE, B_TRUE },
{ SES2_DLUCODE_S_INTERNAL_SAFE,
internal error (reset to revert to backup),
B_FALSE, B_TRUE },
};
#define NUCODE_STATUS \
(sizeof (ucode_statdesc_table) / sizeof (ucode_statdesc_table[0]))
typedef struct ucode_status {
uint64_tus_status;
boolean_t us_iserr;
boolean_t us_pending;
charus_desc[128];
} ucode_status_t;
cheers,
James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: John Plocher John.Plocher at Sun.COM wrote: Garrett D'Amore wrote: Actually, if we (OpenSolaris, Sun, and you) cannot arrive to a suitable understanding, I think the idea of forking the code becomes counter-productive. Yup - maybe at that point we (the community) would choose to not have star in the system at all, but relegate it to one of the add-on software repositories. A small hint: You are not the community, you are John Plocher. If the OpenSolaris project (and the people that control it) is not mature enough for respectful dealings with other OpenSource software projects, then it may be a mistake to start this kind of relationship. As other people don't seem to concur with you, it seems to be a problem with one or two people only and may be fixed. Joerg, John Plocher and Garrett D'Amore are speaking for many people in the OpenSolaris community. Your definition of mature project and respectful dealings appears to only include doing what Joerg Schilling tells them to. I don't think we're getting anywhere, because no matter how many times people make suggestions to you which would assist with what you've stated your goal is, you reject them immediately. This is why we need the equivalent of the linux and *bsd world's non-mainline package repos. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: I am not sure whether it is needed to reply to all parts of the mail. Maybe it is suffiient to point you to a missunderstanding. Garrett D'Amore gdamore at sun.com wrote: If OpenSolaris likes to participate in the advantages from star, Sun cannot try to dictate the development. There is a way to create a symbiosis of OpenSolaris and star, the keyword is collaboration. Your idea of collaboration seems to mean that everything ever written by Joerg Shilling is perfect, must be accepted as is, without change, and that nobody else is allowed to touch code written by Joerg, without his permission. Oh, and that failure to integrate all of Joerg's code is a failure on the part of the community and its sponsors. It seems that you missunderstand collaboration. Shawn Walker came up with a nice definition of collaboration but also failed to understand it: Collaboration means *working towards a common goal*; not dictating what the other party will do. Your proposal was that Sun should take over the star source, remove the portability code and then start dictating how future development should be done. This is defionitely not collaboration. And yet, just about everything you have uttered in this thread indicates to me (and I suspect, Garrett, at least), that unless Sun does what you demand, then you will reject modifications of no matter how good they are, or whether they fix real bugs. That's not collaboration, that's dictatorship. By you, to the rest of the OpenSolaris community. My personal opinion is that we (the OpenSolaris Community) do not need all the autoconf multi-platform configuration stuff which you have written, because we know exactly what it is that we are dealing with. We know which functions we have and how they operate. We know what behaviours we need to work around or apply or whatever. Perhaps you could think of it as a proposal to optimise what you have developed for a particular platform, specifically OpenSolaris. On a personal note, my experience is that if a customer's CEO is on the phone to Sun's CEO/President/Executive VP of whatever, then fixes for their problems happen. Fast. *Really* fast. If you don't like that, tough. Sun operates a business, with customers that pay lots of money for hardware, software and support. Sun also has shareholders, who (as far as I recall) demand that Sun deliver fixes for customer problems in a timely fashion. Here again is my opinion - if you want star to replace Sun's existing version of tar/pax/rmt//whatever, then you will have to play by _Sun's_ rules for the sandbox. That to me means relinquishing absolute control over the codebase and accepting a status which might be described as The One To Go To For Star ... unless you personally commit to the ongoing maintenance of the codebase _as Sun's customers might require_. Insisting that only one person be blessed with the permission to modify the code is not how organisations actually deliver software, because organisations have to have contingency plans and succession plans. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
arcmsr dma problem
Tobias Oetiker wrote: Is there any news on the arcmsr issue with Xen/xvm ? I have now configured my setup with the dom0_mem=1024M boot option, but this does not seem to have any positive effect ... as soon as I try to copy a large file (iso image) around in my zfs (raidz2) I get the infamous arcmsr0: dma map got 'no resources' error and my dom-0 is dead ... Hi Tobias, Haven't seen that issue, no. Need a bit more data from you as well: - which build of NV are you running? - Does this happen in each of your dom0 and domUs? - What is your exact zpool config? - need the output from prtconf -v and prtpicl -v thanks, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
PSARC 2008/196 libscsi and libses
Joerg Schilling wrote: Mike Shapiro mws at sun.com wrote: Please do not call something libscsi unless you prove that this library really an abstraction from the low level transport interface and the Solaris platform. That's what libscsi is. Then send an interface description to allow to check whether this is true... The preface that Mike added to the original email said A copy of the spec (below) is also saved in the incept.materials directory, and I've also put copies of header files there. I expect - since this is an Open fasttrack - that the materials should show up on opensolaris.org fairly soon. Perhaps you might want to check the directory http://opensolaris.org/os/community/arc/caselog/2008/196 in a few hours (give the synchronisation time to occur). James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: Garrett D'Amore gdamore at sun.com wrote: What GNU software does is basically to follow the documentation for autoconf. This is: take this code fragment and copy it into your source. What /usr/include/schily/ and /usr/include/ast do is to put the portability code _once_ into a central location instead. Okay. But that isn't what we've been asked to review. What we've been asked to review is a couple of utility programs and a supporting library. Creating a portability layer and exposing that to the rest of ON was not part of the case materials. Well, I remember that a similar case (made for ksh93 integration) did already add such a portability layer although (using the same rules as for star) the ksh93 case needs those files only for private interfaces. The star integration adds more than private interfaces, note that librmt is supposed to be used by ufsdump/ufsrestore too. As far as I can see, this case does not propose changing ufsdump/ufsrestore to use librmt. Such changes would be more suited to a followup case, and should definitely not be snuck in. ... No, not really. If you want to create a new portability layer, then please propose a new case. This case is about the rmt and star application programs, and the supporting librmt. This is not a new portability layer. It is in use since more than 15 years. In use in /opt/schily/ ? Or in use in /usr/include ? It appears to be new *to OpenSolaris* and that is what counts here. Going through the case materials further, I'm pretty unhappy about the paucity of documentation in librtmt(3). It contains references to things like rmtinit(), but no actual documentation -- not even a function prototype. This is insufficient information for ARC to properly review these APIs, nor for developers to use them. If you like to discuss the internals of librmt, I would encourage you to first read the man pages... If you can accept a phased integration as several people have already suggested, then we don't need to worry so much about manpages etc and header files for librmt and /usr/include/schily/... James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Meld - graphical diff/merge tool [PSARC/2008/189 FastTrack timeout 03/17/2008]
Jim Walker wrote: James C. McPherson wrote: Danek Duvall wrote: I'm sponsoring this fast-track for Jim Walker. The case times out next Monday, March 17. The man page is in the case materials directory. ... From the manpage: NOTTES Source for meld is available on http://opensolaris.org. (a) should be obvious s/NOTTES/NOTES/ - I'll take care of that. :-) (b) shouldn't we provide the sourceforge url here too? How about this? NOTES The meld project is located at http://meld.sourceforge.net. Source for meld is also available on http://opensolaris.org. That works for me. (c) where on opensolaris.org? Downloads? onnv-scm community pages? This is how it is currently written in many SFW packages: http://tas.sfbay/net/sfwnv.eng/gates/sfwnv/gate/usr/src/cmd/gmake/sunman-stability http://tas.sfbay/net/sfwnv.eng/gates/sfwnv/gate/usr/src/cmd/flex/sunman-stability http://tas.sfbay/net/sfwnv.eng/gates/sfwnv/gate/usr/src/cmd/expect/sunman-stability ... I was just being consistent. Also, I assume the location may change, and this wasn't very pretty... http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/meld That's ok by me, just wanted to see how it's currently being done so we're consistent. thanks, James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
Joerg Schilling wrote: James C. McPherson James.McPherson at Sun.COM wrote: Well, I remember that a similar case (made for ksh93 integration) did already add such a portability layer although (using the same rules as for star) the ksh93 case needs those files only for private interfaces. The star integration adds more than private interfaces, note that librmt is supposed to be used by ufsdump/ufsrestore too. As far as I can see, this case does not propose changing ufsdump/ufsrestore to use librmt. Such changes would be more suited to a followup case, and should definitely not be snuck in. The definitions in /usr/include/schily/ are not only used by star but by many other programs - some of these programs are already on Solaris. They are needed if you like to use interfaces from libschily, libxtermcap, libfind, libdeflt, libparanoia, librmt, libscg/librscg I don't have any of those libraries installed on my SXCE build 83 system. They are not required for any currently integrated part of OpenSolaris. In the future, I'm sure they will be required, but today they are not. Paper tigers don't help your argument. Other people have asked you why /usr/include/schily contains such files as param.h and utypes.h. Since we already ship the file /usr/include/sys/param.h, what benefit does having a private copy in /usr/include/schily serve? /usr/include/schily/ is a portability framework. It is needed by every program that likes to use one or more of these libraries. This is not a new portability layer. It is in use since more than 15 years. In use in /opt/schily/ ? Or in use in /usr/include ? It appears to be new *to OpenSolaris* and that is what counts here. If you like to discuss the interfaces in /usr/include/schily/, you are too late. If you like to influence new interfaces, you need to cooperate when new interfaces are defined. Moving the interfaces now found in /usr/include/schily/ to that library has been done 1.5 years ago and it has been discussed on the star integration mailing list and on the ksh93 list. You had the chance to influence this change 1.5 years ago as this change has been done only to make the integration itno OpenSolaris easier. Again, that is not actually the point. What is the point here is that - we don't need to provide /usr/include/schily/ in order to deliver librmt, star and friends. Insisting on delivering these interfaces makes them a roadblock to getting your code integrated. You have a Sun engineer willing and able to help you, and a community group which (as far as I can see) is more than happy to help as well, and you are insisting that Interfaces (note the I) be delivered when they are not actually required for Joe Random User to make use of star et al. We, the OpenSolaris community, do not need /usr/include/schily *right now* in order to make use of star. The horse is dead, stop beating it. I mentioned several times that there is already /usr/include/ast/ which includes interfaces used by a single program (ksh93). Libfind and other libraries offer innovative interfaces used by several programs that are already on OpenSolaris and it is of interest for a lot of other programs. If you believe that /usr/include/schily/ should not appear in OpenSolaris, please remove /usr/include/ast or explain why ARC discussions are not rule based. I'm not saying that /usr/include/schily should not appear in OpenSolaris. What I am saying is that *FOR THIS CASE* the /usr/include/schily file list *appears to be* an impediment to getting star et al integrated. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
On Wed, 27 Feb 2008 10:28:27 +0800 Tzongyu Paul Lee Tzongyu.Lee at Sun.COM wrote: (Forgot to attach the header/intro portion for the case..) I am sponsoring this fast-track for James C. McPherson. Requested release binding is patch, and the timer is set to 03/04/2008. T.Paul --- Tzongyu Paul Lee ??: Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Pluggable fwflash(1M) Ahem, I have a small modification to the spec - one grammatical error and one additional structure member: 32c32 identification and firmware verification requires. By keeping the --- identification and firmware verification requirements. By keeping the 157a158,172 * We also store the name of the firmware file that * we point to with *fwimage. This is needed in cases * where we need to key off the name of the file to * determine whether a different buffer in the target * device should be targeted. * * For example, our standard firmware image (file.fw) * might require use of buffer id 0, but a boot image * (boot.fw) might require use of buffer id 17. In each * case, it is the verifier plugin that determines the * specific bufferid that is needed by that firmware image. */ char *imgfile; /* The new version of the spec is attached. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog -- next part -- An embedded and charset-unspecified text was scrubbed... Name: pluggable_fwflash.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080229/4d18cd97/attachment.txt
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
On Wed, 27 Feb 2008 11:45:20 +0100 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: Tzongyu Paul Lee Tzongyu.Lee at sun.com wrote: (Forgot to attach the header/intro portion for the case..) I am sponsoring this fast-track for James C. McPherson. Requested release binding is patch, and the timer is set to 03/04/2008. T.Paul --- Tzongyu Paul Lee : Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Pluggable fwflash(1M) 1.2. Name of Document Author/Supplier: Author: James McPherson 1.3 Date of This Document: 26 February, 2008 4. Technical Description That is the reason for trying to use a generic name for a utility that only works with a limited subset of SCSI devices? Hi Joerg, I don't understand your question. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
On Wed, 27 Feb 2008 12:38:16 +0100 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: James C. McPherson James.McPherson at Sun.COM wrote: That is the reason for trying to use a generic name for a utility that only works with a limited subset of SCSI devices? Hi Joerg, I don't understand your question. If you would be able to do a firmware upgrade with various CD/DVD writers, I would see no problem with using a generic name. Otherwise, please a more descriptive name. Part of the point in being pluggable is genericity. The architecture which I am proposing is generic enough to support flashing HBA firmware as well as direct-attach devices such as disks, CD/DVD-ROM and tape drives. The name fwflash was suggested by PSARC in an earlier case and agreed to by that particular project team. In your opinion, which aspect of the name fwflash is not descriptive enough, and what do you suggest we call this utility instead? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Pluggable fwflash(1M) [PSARC/2008/151 FastTrack timeout 03/04/2008]
On Wed, 27 Feb 2008 12:00:08 + Darren J Moffat Darren.Moffat at Sun.COM wrote: James C. McPherson wrote: The name fwflash was suggested by PSARC in an earlier case and agreed to by that particular project team. In your opinion, which aspect of the name fwflash is not descriptive enough, and what do you suggest we call this utility instead? I don't see changing the name of the already existing fwflash command is in scope for this project. fwflash(1M) was declared as Stable in 2005/126 which makes it Committed in the new taxonomy. This case needs patch release binding so changing the name is not an option. I totally agree. James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
arcmsr dma problem (was: arcmsr SAS/SATA RAID driver)
Tobias Oetiker wrote: ... Now the the driver is about to be integrated, I think it would be a good thing to look at that dom0 dma problem. I just was hit by it yesterday running arcmsr version 1.20.00.15 (firmware v1.43) on svn_79a / v3.0.4-1-xvm see also http://opensolaris.org/jive/thread.jspa?threadID=41581tstart=135 Hi Tobias, I haven't come across this problem in my testing. Could you describe your configuration please, how often you can reproduce this message, and what your system is doing when this message is observed. thankyou in advance, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
ksh93 Update 1 [PSARC/2008/094 FastTrack timeout 02/15/2008]
Joseph Kowalski wrote: Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ksh93 Update 1 1.2. Name of Document Author/Supplier: Author: Roland Mainz 1.3 Date of This Document: 08 February, 2008 4. Technical Description I'm sponsoring this fast-track request on behalf of XXX. XXX. Hmm. Now is that the father of , or did you actually mean to specify Roland? James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
arcmsr SAS/SATA RAID driver [PSARC/2008/079 FastTrack timeout 02/12/2008]
Please find attached an updated spec for the fasttrack. Diffs are as follows: --- integrate_arcmsr.txt.orig Sat Feb 9 14:37:10 2008 +++ integrate_arcmsr.txtSat Feb 9 14:38:35 2008 @@ -1,3 +1,4 @@ + Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2008 Sun Microsystems @@ -43,7 +44,7 @@ This project will integrate Areca Technology Corp's Solaris x86/x64 driver, namely arcmsr, into Solaris. - This driver supports Areca's SATA raid cards + This driver supports Areca's SATA RAID cards ARC-1110, ARC-1120, ARC-1130, ARC-1160, ARC-1170, ARC-1201, ARC-1210, ARC-1220, ARC-1230, ARC-1260, ARC-1270, ARC-1280 @@ -232,12 +233,13 @@ 4.10. Packaging Delivery: The arcmsr(7d) driver will be delivered only on the x86 and x64 architectures. - The arcmsr(7d) driver will be included in SUNWckr as: + The arcmsr(7d) driver will be included in the SUNWCmreq cluster as: /kernel/drv/arcmsr /kernel/drv/arcmsr.conf /kernel/drv/amd64/arcmsr + A new package, SUNWarcmsr, will be created to contain the deliverables The arcmsr(7d) manpage will be included in SUNWman. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog -- next part -- An embedded and charset-unspecified text was scrubbed... Name: integrate_arcmsr.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080209/607ce48c/attachment.txt
arcmsr SAS/SATA RAID driver [PSARC/2008/079 FastTrack timeout 02/12/2008]
I've attached a draft manpage for arcmsr(7D) to this email. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog -- next part -- An embedded and charset-unspecified text was scrubbed... Name: arcmsr.7d.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080209/97573b15/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: arcmsr.7d URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080209/97573b15/attachment.ksh
arcmsr SAS/SATA RAID driver [PSARC/2008/079 FastTrack timeout 02/12/2008]
James Carlson wrote: James C. McPherson writes: Since it is expected that arcmsr would provide attachment to a bootable OS target, I want to provide a buffer so that a system admin keen on minimisation would not inadvertently remove the driver supply access to their OS instance. That's an argument for putting the new package into SUNWCmreq, not an argument for putting the binaries into an existing package. Yep, I agree totally. I'm not particularly wedded to one or the other choices for the package, and I would like to canvass the opinions of the wider community on this issue. Unless there's a clear reason why *every* system, including those without the corresponding hardware, must have this driver, I'd suggest a separate package. I'll put it into a separate package, but request that the package be part of SUNWCmreq. Thankyou, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
arcmsr SAS/SATA RAID driver [PSARC/2008/079 FastTrack timeout 02/12/2008]
Garrett asked me two followup questions about this fasttrack. Firstly, I haven't addressed the Big Rule question regarding SPARC support with arcmsr. Secondly, why request integration into SUNWckr rather than create a new package? Re the Big Rule question: I don't currently have sufficient hbas (I only have one at the moment, courtesy of Areca's CEO) to test the driver on the SPARC platform. Delivering SPARC support in arcmsr is on the roadmap for Phase 2. Re the package integration choice: Since it is expected that arcmsr would provide attachment to a bootable OS target, I want to provide a buffer so that a system admin keen on minimisation would not inadvertently remove the driver supply access to their OS instance. Garrett mentioned that providing a SUNWarcmsr or similarly-named package would make it easier to minimise a system too. I'm not particularly wedded to one or the other choices for the package, and I would like to canvass the opinions of the wider community on this issue. Thankyou and best regards, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
[Fwd: Re: Integrate mfi (OpenSolaris MegaRaid SAS) driver [PSARC/2008/011 FastTrack timeout 01/16/2008]]
Hello all, John Plocher requested that the interested parties in mfi and megasas get together and talk. We've been talking productively over the last week or so, and we are making progress on a way forward which I believe satisfies the needs of all concerned. In the next few days I expect to be able to provide updated materials for 2008/011 which reflect our proposed solution. Thankyou and best regards, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
[Fwd: Re: Integrate mfi (OpenSolaris MegaRaid SAS) driver [PSARC/2008/011 FastTrack timeout 01/16/2008]]
Alan Hargreaves wrote: For what it is worth, we have current precedent for having an open driver available in nevada and a driver that can be downloaded and instaleld from the vendor. We provide bge as opensource in the open tree of ON and Broadcomm make bcme available for download from their site. On pkgadding bcme the admin is asked if they want to disable the bge driver to avoid conflict. Seems like a lot of similarities to me here. Hi Alan, thankyou for pointing this out. One difference though is that we've been assured from day 1 that LSI want their driver integrated into the ON gate rather than into some other IHV-specific gate. Either way, could we have more time to complete the back-channel discussions between various managers please. An extension of the timer rather than a complete derail is my preference. thankyou again, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
[Fwd: Re: Integrate mfi (OpenSolaris MegaRaid SAS) driver [PSARC/2008/011 FastTrack timeout 01/16/2008]]
Alan DuBoff wrote: On Fri, 11 Jan 2008, James C. McPherson wrote: ... Hanging around for months waiting, being continually reassured in non-public conversations that allegedly better code is going to get integrated is *NOT* a useful way of encouraging other driver authors to bother offering their code to Sun for inclusion in OpenSolaris. Yes, I agree, but we get more. We get the vendor to support their own hardware, and I think that's preferable. We get an open source driver from LSI, that in itself could be a first (I know you're skeptical), and we get management software for the driver, although it won't be open, I think you will agree that having management software for RAID is desirable for any user. Hi Alan, with the above in mind, please tell me when you or Pat plan to provide: - ARC materials for megasas in Solaris - ARC materials for the megasas management utils in Solaris - the date by which time megasas driver and management code will be delivered by LSI to Sun James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
[driver-discuss] MFI vs. Megasas
Richard Lowe wrote: But surely over in OpenSolaris land we have raidctl, which while currently specific to mpt-driven cards (I think), seems clearly intended to be generic. I assume that the mega_sas actually intend to integrate a raidctl plugin, rather than a separate CLI? Best not to assume anything - Alan Duboff's team has not yet provided any ARC materials so it's still vapourware. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
[ogb-discuss] Project proposal - Integration (MFI driver for LSI network chipsets)
Hi John, John Plocher wrote: [I'm not sure why this is an OGB-Discuss discussion and not an ARC one...] Should be slam dunk to get the mfi putback. Without having seen any of the details of this project, there are two architectural level issues that jump out at me. One is that of an incompatible change, the other is knowing about a future train wreck. Issue 1: On SX, we currently have a mix of open and closed source components that includes a closed driver for this chipset. Actually, we do not already have a driver of any sort for this chip and card in Open or closed Solaris. David's mfi driver is for the LSI MegaRAID SAS product. The drivers which we already have in Solaris are - lsimega, for the U320 parallel scsi raid controller, and - mpt, for the U160/U320 parallel scsi onboard controller and for the LSI 1064/1068E SAS hbas. Both chip families that mpt controls can do raid. This project seeks to replace that driver with a different one, such that some new version of SX will behave differently. The issue is what are those differences? If they are along the lines of something that works today will break tomorrow, then from a systems engineering perspective, we have a problem, and will need to take steps to address the disconnect. No. The issues start with Sun getting in the way of OpenSolaris having an open, BSD-licensed driver for hardware which is incredibly popular. This getting in the way appears to stem primarily from being told by LSI words to the effect of We're really truly going to sign the appropriate legal agreements real soon now so you can have our megasas driver ... Those promises have been in train for well over a year as far as I am aware. There is, understandably, a great deal of frustration on the part of David and several other involved parties. Issue 2: We know that the current state of the networking stack is not very friendly to driver changes (renames, multiple drivers for a single device, ...) - to the point where it is effectively impossible to mechanize/automate/releasenote all the steps needed to successfully remove one driver and replace it with a different one (yes, vanity names will help lots in this area, but they are not there yet). If we have reason to believe that we will have multiple drivers for the same network device, we know we will end up with a problem when they both end up in the same system. Because the system does not (yet) support this situation, we need to take steps to avoid it. What exactly those steps might be is beyond the scope of this email discussion and into the realm of ARC review. We all understand the conflicting desires that are in play, as well as the technical hurdles. Our job is to chart a course thru them all that gets us to the destination with the fewest casualties. This second issue is one that has always been on my mind and which I have given some thought to from time to time. I have not, as yet, been able to come up with a mostly foolproof way of working around it. Of course, not actually having LSI's driver has made it rather difficult to even test hypotheses. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Host Protected Area (HPA) on x86 ATA drives [PSARC/2007/660 FastTrack timeout 11/28/2007]
Alan Perry wrote: Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Host Protected Area (HPA) on x86 ATA drives 1.2. Name of Document Author/Supplier: Author: Lawrence Lee 1.3 Date of This Document: 19 November, 2007 ... Examples: ... - Don't change the HPA setting on all but two disks. Make one disk a 200GB drive (390625000*512 = 200,000,000,000) Give the other disk a 1MB Protected area HPA=*, pci at 0,0/pci-ide at 6/ide at 0, -390625000, pci at 0,0/pci-ide at 6/ide at 1, 2000; More details/examples are available in the Evaluation section of CR 5044205. Hi Alan and Larry, how is the customer supposed to know that they should use a signed integer for the length/size field? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
System property to control mpt driver bus release timeout feature [PSARC/2007/547 FastTrack timeout 09/26/2007]
Tzongyu Paul Lee wrote: Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: System property to control mpt driver bus release timeout feature 1.2. Name of Document Author/Supplier: Author: Kevin McInerney 1.3 Date of This Document: 19 September, 2007 4. Technical Description System property to control mpt driver bus release timeout feature ... 4. References LSI Fusion-MPT Message Passing Interface Specification v1.5.2 http://lagoon.central/docs/rpe-drivers/solaris-kernel-driver-mpt/FusionMPT_MPISpec1-5-2.pdf PSARC 2001/401 MPT driver (message passing technology) ... 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 Hi Paul, since this fasttrack depends upon NDA-covered documentation which is not available outside of Sun, I don't think it is correct to provide a pointer to the pdf. I'm also not sure that this fasttrack should be visible outside of Sun. best regards, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
James Carlson wrote: Darren J Moffat writes: James Carlson wrote: Using that binding means Nevada only for now, the same as a Minor release binding. I don't see why it is confusing. To me that says that is is low risk It's confusing because many project teams use Micro by mistake when they actually mean Patch. We then run into last-minute updates when the C-team calls them on it. It's almost always an error. I have no problem with Micro when used correctly -- though it's slightly odd when there are no Micro vehicles around and none contemplated -- but the chance of error seems high. Following up on your and Bill's question, we're requesting a Minor binding for the rfe. Are there any other issues or questions that we need to address with this RFE - at least from PSARC's point of view? thankyou in advance, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
Jason King wrote: Missed you on the CC.. -- Forwarded message -- From: Jason King jason at ansipunx.net Date: Sep 5, 2007 5:29 PM Subject: Re: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] To: Bill Sommerfeld sommerfeld at sun.com Cc: Alan Hargreaves ah89892 at sac.sfbay.sun.com On 9/5/07, Bill Sommerfeld sommerfeld at sun.com wrote: I don't see a statement of interface stability or a release binding (Minor? Patch?) The only thing that makes this arc-visible is the fact that there are in fact some minor changes to the instruction decoding; replacing one implementation with another that behaves exactly the same is a non-event. So something changed but the case is silent on this... I would have expected a brief summary of the discussion on opensolaris-code as part of the case materials. I don't have the necessary background on Sun's policy for release bindings to state what the appropriate answer would be, nor to comment in the interface stability. I would suspect for the interface stability at least, it would match whatever the current classification for the current library is. We're requesting a release binding of micro. There's no intention of pushing this back into Solaris 10. As for changes, there are a few cases where the current closed source bin outputs incorrect output (unfortunately, the sparc system I have been using for testing is unavailable at the moment, so I cannot give specific binaries for examples right now, though I can comment on the errors themselves). I have not carried those forward. There are some cases where it is inconsistent about it's use of synthetic instructions -- this one gets very hard to nail down without access to the current source. For example, 'not' is only emitted in certain cases, even when it would be correct in others. I just opted to emit 'not' whenever the conditions were correct, instead of trying to figure out which permutations happened to get 100% same behavior. Would documenting which synthetic instructions are emitted, as well as which instructions the current library outputs incorrectly satisfy any ARC requirements? As for interfaces, I also don't have any way to know if there are any existing undocumented interfaces that otherwise might change. The one thing I guess might be considered a new interface is in the .so version (as opposed when it's built for kmdb), it supports the setting of an environment variable _LIBDISASM_DEBUG that can cause information about the instruction decoding to be sent to stderr as well as control the use of synthetic instructions. I'm not sure what would an appropriate classification if this is something that needs to be documented. Just let me know what needs to be done. Re the ARC-visibility, my understanding was that we needed a fasttrack due to moving from closed to open. I'm quite happy to be mistaken on that front! James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems
krb5_ldap_util command for Solaris Kerberos [PSARC/2007/368 FastTrack timeout 06/26/,2007]
Wyllys Ingersoll wrote: I am sponsoring the following fast-track for Will Fiveash. * The release binding is patch/micro. * The interface stability is committed. * The timer is set for 1 week (6/27/2007) - Wyllys Ingersoll Should something marked This information is Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know and containing names of customers really have been sent to psarc-ext? Couldn't you have redacted the customer names before sending it out? James C. McPherson -- Solaris kernel software engineer Sun Microsystems
Fast track review - PSARC/2007/284 Dwarf Caiman, New Solaris Install GUI - updated spec
Wyllys Ingersoll wrote: ... 3.1.4 The SunStudio and NetBeans tools: 1. Initial Install: a) Installation behavior and scripts are provided by the Developer tools team. b) During initial install Sun Studio 12 will be installed. Hi Sarah, to the best of my knowledge you cannot build the Nevada gate (and thus OpenSolaris) with Studio 12. I was under the impression that being able to build OpenSolaris with an out of the box SXDE installation was a target of the SXDE releases. James C. McPherson -- Solaris kernel software engineer Sun Microsystems
